Would like to see the ability to load a report based on the language. Currently thinking that all reports for a language would be housed in a folder, so if lv/report_path.frx existed it would load that first. But if it did not exist, we should look for report_path.frx instead. The user interface of the report designer would need to allow the user to specify the language when saving/renaming a report.

CommentFileSizeAuthor
#2 forena_ajax_err.jpg39.56 KBjaneks

Comments

metzlerd’s picture

Status: Active » Fixed

Latest commit to 7.x-2.x-dev has this code in it. A new translation tab has been made available to facilitate the translation of reprots. The "My Reports" list has been modified to show only the reports in the current language.

janeks’s picture

Category: feature » bug
Status: Fixed » Needs review
StatusFileSize
new39.56 KB

Hitting * into format field (of a report field form) gives ajax error. See attached.

janeks’s picture

Sorry for previous post - it was intended for another issue: http://drupal.org/node/1442558

But the problem with this was that I added translation. Switch between languages worked well, but non original (lv) language lost parameters.

metzlerd’s picture

Status: Needs review » Fixed

Corrected the bug about loosing parameters. Pushed commit.

janeks’s picture

Status: Fixed » Needs review

Solved partially - there are Parameters available under Parameters configuration tab, but still no parameters on View tab.
Also found that export options on another non English (or non original) View tab are visible all of them, while under Layout configuration there are checked just two of them.

metzlerd’s picture

Can't reproduce this. Are you sure this wasn't a bad report from the old bug? Could you delete and recreate the translation report to verify that this is still the case?
I did push a fix related to do with translating reports in subdirectories so you might want to update your code.

metzlerd’s picture

An important thing to understand is each translated report is completely separate. That means that if you need to change export options on one, you need to change export options on each translation. This is true for parameters and fields. There are completely separate reports in play. Discovering that there are still some bugs when navigating the report editor in non-english language. Will need more work to get solid.

janeks’s picture

BTW, minor: When creating new report under layout tab the language drop down value differs from current language.

My test (current default language - Lv):
1) Created new report - o'k
2) Add data block with parameter value - o'k
3) Editing layout tab (found the minor bug above), changed English to Latvian. Lost default parameter. But I can change/save them again and then it worked.
4) Tried to add English translation - error:
Could not find requested page: "/?q=lv/reports/test_report_0301/layout&language=en" .

I observed that when creating new translation it does not allow the same name of report, but here it asks for it.

metzlerd’s picture

I pushed a new version that should fix these latest problems. Could you re-test?

janeks’s picture

Fixed:
error: Could not find requested page: "/?q=lv/reports/test_report_0301/layout&language=en" .
and that translation did not allow the same (system) name of report.

Minor things left:
Point 3) from my previous post.
It is a bit confusing that when if the current language is switched than the current report language is not switched. It would be o'k if all report parameters would be on one page or that when editing report settings/params/etc. we could see the current report language. Another approach could be that when we click add/edit report for another language, than sites current language is also switched.

janeks’s picture

Report deletion should be fixed:
Now I can delete one of translated/localized report, after that report is partialy broken.

metzlerd’s picture

I don't quite understand what you mean by partially broken. What is the symptom?

janeks’s picture

When switching to deleted (en) report(translation?) View tab:
Notice: Undefined variable: r_text in FrxDrupalApplication->load_report() (line 142 of ...\sites\all\modules\forena\FrxDrupalApplication.inc).
Notice: Undefined variable: r_text in FrxDrupalApplication->load_report() (line 150 of ...\sites\all\modules\forena\FrxDrupalApplication.inc).
Could not load report. Check for invalid XML.

Data, Fields, Layout tab:
The requested page "/?q=en/reports/test24/data" could not be found.

Parameters tab:
Notice: Undefined index: exists in forena_admin_params_form() (line 1768 of C:\www\ForemsDrupalReporting\sites\all\modules\forena\forena.admin.inc).
and the same as above.

When switching to Lv (left or not deleted report) View tab shows report.

Data tab:
Notice: Undefined index: exists forena_data_block_form() (rinda 1270 no C:\www\ForemsDrupalReporting\sites\all\modules\forena\forena.admin.inc).
and
Pieprasīto lapu "/?q=lv/reports/test24/data" nebija iespējams atrast. (that is in Latvian the same that for En - could not find...)

Fields and Layout tab:
Pieprasīto lapu "/?q=lv/reports/test24/data" nebija iespējams atrast. (that is in Latvian the same that for En - could not find...)

Parameters tab:
Notice: Undefined index: exists forena_admin_params_form() (rinda 1768 no C:\www\ForemsDrupalReporting\sites\all\modules\forena\forena.admin.inc).
and
Pieprasīto lapu "/?q=lv/reports/test24/data" nebija iespējams atrast. (that is in Latvian the same that for En - could not find...)

Translation tab shows correct info.

metzlerd’s picture

I've just pushed some bug fixes that I think will correct (some) of these problems, but I'm not quite experiencing them the same way that you are. I have been completely unable to reproduce the bug about parameters carrying through from the original report. There are probably still improvements that can be made, but I might need more specific pathways to reproduce the problems.

I'll try and find time to make sure that we know what language was loaded on the forms, but I am considering a major rework of the report editing interface anyway that takes advantage of the improved ajax support in drupal, so I don't want to waste to much time perfecting a user interface for forms that I'd like to rewrite anyway.

Thank you for your time in testing this.

metzlerd’s picture

Status: Needs review » Closed (fixed)

I've been working with Janeks directly and it seems that the code base has stabilized. Marking this one as done.