Anonymous Login
2022-10-05 18:57 PDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000549v2.1 Release (Closed)[All Projects] Generalpublic2010-09-21 23:04
Assigned Topedroa 
Product Versionv2.1 
Target VersionFixed in Versionv2.1 
Summary0000549: upon deinstalling a module the language for the module name is switched to English (for reinstall)
Descriptionafter following your advise to deinstall the links (Verweise) module I got a little shock - there was no module listed to reinstall.

Later realised that it switched its name from German to English - there is no 'Verweise', but 'links' can be reinstalled.

In principle, there should be consistent language handling.
Either always links, or always Verweise.

very looooow priority.
TagsNo tags attached.
Attached Files




caseydk (administrator)

I *think* it only loads a module's translation if the module itself is loaded. Honestly, I've kept my hands out of translations - they generally work, I only speak English - so a second opinion would be good here.



pedroa (administrator)

Yes only if a module is active, its translation file is read.

There is only one translation file that is commonly read throughout the application and it is the translation file.

On the case of the interface that Klaus is talking about, besides the file, also the and the are read.

I understand the "consistency" point.
Considering the way it works, we could "fix" this issue by changing line 122 of /modules/system/viewmods.php from:

        $s .= '<td>' . $v . '</td>';


        $s .= '<td>' . $AppUI->_($v) . '</td>';

And then add the necessary translation strings to locales/en/
Then the users would translate it into their languages and it would work alright. (I said that because I tested it and it worked alright)

Problem is we can not guess the strings of add-on modules, or they'd need to be added to that file as we took knowledge of their existence, for translation sake.

What we can do is to make that change and at least make sure that the core modules translation strings are in that file.

Sounds good?


Pedro A.


opto (manager)

can the strings of addon modules come from another included file? So that each module directory would bring its own translation?
Never checked how w2p does it, but I think that is the approach vtiger uses.
So addon modules can be brought into the system without changing the translations for core.
Or put it (file name) into the db?


pedroa (administrator)

Add-on modules may have their own .inc files

As you can read on lines 30 to 33 of the /locales/core.php file
(This is the file that reads the translations into memory)

// language files for specific locales and specific modules (for external modules) should be
// put in modules/[the-module]/locales/[the-locale]/[the-module].inc or
// modules/[the-module]/locales/[the-locale].inc
// this allows for module specific translations to be distributed with the module

Cool, but that file only reads the translation file for the module your URL is at. Why? Performance and less memory usage.
So we don't read all the translation files for all the active (or whatever) modules at any given time. We only read the ones necessary considering the module you are at.

So add-on modules or not everything can be used on the Translation manager as long as it has an .inc file in english which server as translation string keys to be used for other languages.

As to using the DB, I think it is not necessary, because as is it works fine.

Now as we were chatting, I believe there is another solution, but a rather more complex one, and that is to load any existing modules .inc files if $m = 'system' and $a = 'viewmods'

Still we need that $AppUI->_() on viewmods.php

Two solutions with pros and cons:
1st) Add any known modules string keys to /locales/en/
PROS: Faster fix, better performance by not loading every single .inc file into w2P
CONS: The fix is fast because we only need to add modules name strings to one file, but to have it really fixed we'll need to wait for the community to provide translated .inc files before the users see the strings correctly translated on their interface.

2nd) Add an exception on the /locales/core.php file so it loads any existing .inc file (on locales as well as modules), to make sure translation is done on this specific interface (m=system and a=viewmods)
PROS: This way we are sure we don't miss it, and that we don't need anyone to translate anything for us.
CONS: Performance hit on this interface as web2project needs to seek and read every .inc file around into memory. Could be unnoticeable on fast systems or not. Putting too much effort on the system to just read a small bunch of strings.

2 options, 1 decision.


Pedro A.


opto (manager)

Well, the translation problem only occurs in module management for install. In the other cases, the current transöation works fine, as far as i know.
Does w2p at this point know which locale is used? If yes, it only needs to read that locale translation file, not the others. Which it would do anyway if the module were installed.



caseydk (administrator)

The problem is that translations are basically an array held in memory. Generally, they're separated by context f knowing which module you are currently in.. but if you load all of them on this screen, the context is thrown off and I have no clue what might happen...

Is this an annoyance or a problem? I just think this needs more thought than can happen in the next 2 weeks before the v2.1 release..


pedroa (administrator)

Opted for the first solution and added the missing translation strings for removable modules and all add-on modules on web2project-mod SVN repository.

The second solution, though being possible also required having to change the .inc files because the .inc files of much modules do not also provide their own necessary translation strings required to solve the issue here

I'll be giving my own example by sending the updated Portuguese PT .inc files.
Other languages... please follow the example and send them over.
This is a Community product, show us the meaning of it please.


Pedro A.

-Issue History
Date Modified Username Field Change
2010-08-14 04:11 opto New Issue
2010-08-14 06:51 caseydk Note Added: 0001204
2010-08-14 06:51 caseydk Assigned To => pedroa
2010-08-14 06:51 caseydk Status new => feedback
2010-08-14 17:32 pedroa Note Added: 0001206
2010-08-15 03:46 opto Note Added: 0001207
2010-08-15 04:24 pedroa Note Added: 0001209
2010-08-17 11:50 opto Note Added: 0001210
2010-08-24 23:31 caseydk Note Added: 0001233
2010-08-28 17:48 pedroa Note Added: 0001238
2010-08-28 17:48 pedroa Status feedback => resolved
2010-08-28 17:48 pedroa Resolution open => fixed
2010-08-30 22:13 caseydk Project v2.0 Release (Closed) => v2.1 Release (Closed)
2010-09-21 22:11 caseydk Status resolved => closed
2010-09-21 22:39 caseydk Status closed => resolved
2010-09-21 22:46 caseydk Status resolved => closed
2010-09-21 22:46 caseydk Fixed in Version => v2.1
2010-09-21 23:04 caseydk Product Version => v2.1
+Issue History