View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
---|---|---|---|---|---|---|---|---|---|
0000714 | v2.3 Release (Closed) | [All Projects] General | public | 2011-02-06 10:47 | 2011-03-24 09:50 | ||||
Reporter | eureka | ||||||||
Assigned To | caseydk | ||||||||
Priority | normal | Severity | feature | Reproducibility | N/A | ||||
Status | closed | Resolution | fixed | ||||||
Product Version | 2.3 | ||||||||
Target Version | Fixed in Version | 2.3 | |||||||
Summary | 0000714: Make add-on module names translatable | ||||||||
Description | I suggest adding the name (mod_ui_name) of the add-on modules in the file "locales/en/comminc.inc" in order to make them translatable. These names are : FlexReports Help Desk Mantis Notebook Project Importer Risks Time Card TodoList Working time | ||||||||
Tags | No tags attached. | ||||||||
Attached Files |
|
![]() |
|
eureka (reporter) 2011-02-06 10:51 |
i meant: locales/en/common.inc sorry ! |
Pierre (reporter) 2011-02-17 08:59 |
Are you talking about 3rd party modules? Optional things? I am not really into the whole project here (yet) but I find it be better to have each module keep it's translation instead of putting it in one global project file. If I were to make a new module for subversion integration, it is totally not realistic to assume I add it to this file mentioned. Instead it must be contained in my module "space". Since I assume this is the best way, I would even do this for all modules. Why handle internal modules different from the outside ones? I know it's not so good to have localization spread out, but this way it's at least consistent. |
eureka (reporter) 2011-02-17 09:23 |
Pierre, When the menu bar is displayed, the language file of the module is not yet loaded Do you have a better solution? |
Pierre (reporter) 2011-02-17 23:49 |
I have not looked into how modules work. But it seems there is some way to install modules. Why not integrate into the install process some basic loca text exchange? So by installing a module it the module name (or whatever else is important) will be stored in the database for all available translations. |
caseydk (administrator) 2011-02-18 21:13 |
@Pierre - Good idea. The module install should handle adding these terms to the translation files. The only potential issue I see is with file permissions but if someone is using non-English already, odds are that the permissions are correct. @Eureka - what do you think? |
eureka (reporter) 2011-02-19 01:59 |
these terms are already in the translation files of the add-on modules but when the menu is displayed, only "common.inc" and the translation file of the current module are in memory (see locales/core.php). the names of other modules remain untranslated. ok, if the module install extracts these terms from the translation files then inserts them in "common.inc" (not in the database) for all available translations. |
caseydk (administrator) 2011-03-22 22:43 |
Resolved in r1760 |
caseydk (administrator) 2011-03-24 09:50 |
Closed in preparation for v2.3 release. |
![]() |
|||
Date Modified | Username | Field | Change |
---|---|---|---|
2011-02-06 10:47 | eureka | New Issue | |
2011-02-06 10:51 | eureka | Note Added: 0001595 | |
2011-02-17 08:59 | Pierre | Note Added: 0001640 | |
2011-02-17 09:23 | eureka | Note Added: 0001642 | |
2011-02-17 23:49 | Pierre | Note Added: 0001646 | |
2011-02-18 21:13 | caseydk | Note Added: 0001647 | |
2011-02-19 01:59 | eureka | Note Added: 0001652 | |
2011-03-22 22:43 | caseydk | Note Added: 0001744 | |
2011-03-22 22:43 | caseydk | Status | new => resolved |
2011-03-22 22:43 | caseydk | Resolution | open => fixed |
2011-03-22 22:43 | caseydk | Assigned To | => caseydk |
2011-03-24 09:50 | caseydk | Note Added: 0001770 | |
2011-03-24 09:50 | caseydk | Status | resolved => closed |
2011-03-24 09:50 | caseydk | Fixed in Version | => 2.3 |