GNOME Bugzilla – Bug 492848
planner HTML export not localized
Last modified: 2021-06-09 20:39:53 UTC
From: https://bugzilla.novell.com/show_bug.cgi?id=219341 When using Planner with German locale, everything in the GUI is German, but when exporting to HTML, the labels are not localized: Everything is in English Examples of such labels: "Company", "Report Date", "Gantt Chart", "Tasks", etc. Checking the code, it looks like the xslt is not setup to do localization.
Using in portuguese it translates everything, so may this bug should be something else.
Perhaps fixed in the mean time?
Well, should be great if you could test it again and give a answer to close this bug.
I could confirm this, bot not in manner JP Rosevear said. I is problem with localization, bot not for entire HTML, but for few dates are printed. I have attached two exported HTML's from PLANNER_0_14_4-24-ge738660 with lithuanian and russian locales (lt_LT.UTF8, ru_RU.UTF8). There you can see "Sep 28", "Sep 29" for english "September" short version, instead of respective translations.
Created attachment 144423 [details] Lithuanian locale HTML export test
Created attachment 144424 [details] Russian locale HTML export test
It looks like there is no request to translate start and end dates ($start_date, $end_date inside html1_tasks.xsl) at all. Gettext ( I18N:gettext() ) does not seems want to translate "date:month-abbreviation". Thought, mrp_time_format could do it - I tried changing default date format inside xslt_module_getdate() to "%b" (get only abbreviation) and it worked (I18N:getdate() returned localized abbreviation for xslt). So either abbreviations should be accessible trough I18N:gettext() (rather cumberstone I guess), or it would be better to have I18N:getdate() or alternative dedicated I18N:getdate_ex() with extra format specifying string argument. I believe it would be helpful to have that (format specifier) for the future. P.S. i could try to fix it if someone of devs could confirm [a better way].
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/World/planner/-/issues/147.