Feature codes translation

Notes:
this looks like a more complex issue. Today's translations are stored with each module which means that translations would be present with each module supplying the featurecodes. However, the featurecodes module is going to be pulling from it's own translations. (and in the current implementation, it is missing the calls to gettext() anyhow). So if the current structure is to continue, the module would need to reset the domain (bindtextdomain()) as it runs through the list of feature codes from each module.

If you have some descriptions translated that are included with the modules that are creating the featurecodes, try this patch - does it get them for you? (please report back):

Index: page.featurecodeadmin.php
===================================================================
--- page.featurecodeadmin.php (revision 5204)
+++ page.featurecodeadmin.php (working copy)
@@ -42,10 +42,15 @@
  <?php
  $currentmodule = "(none)";
  foreach($featurecodes as $item) {
-   $moduledesc = isset($item['moduledescription'])?_($item['moduledescription']):null;
+
+   // change domains to get the translations from each module
+   //
+   bindtextdomain($item['modulename'],"modules/".$item['modulename']."./i18n");
+   $moduledesc = isset($item['moduledescription'])?gettext($item['moduledescription']):null;
+   $featuredesc = gettext($item['featuredescription']);
+   bindtextdomain($dispnum,"modules/".$dispnum."./i18n");
+
    $moduleena = ($item['moduleenabled'] == 1 ? true : false);
-
-   $featuredesc = _($item['featuredescription']);
    $featureid = $item['modulename'] . '#' . $item['featurename'];
    $featureena = ($item['featureenabled'] == 1 ? true : false);
    $featurecodedefault = (isset($item['defaultcode']) ? $item['defaultcode'] : '');

no feedback ... it doesn't seem to hurt anything and I don't have the translations to confirm whether or not it works, so I'm closing this as fixed. Comment back to reopen if you confirm that this does NOT fix the problem.

r5359

Replying to p_lindheimer:

no feedback ... it doesn't seem to hurt anything and I don't have the translations to confirm whether or not it works, so I'm closing this as fixed. Comment back to reopen if you confirm that this does NOT fix the problem. r5359

This patch NOT fix the problem. I have pathed file page.featurecodeadmin.php, and tried create .po file with xgettext/ This is the result:

#: page.featurecodeadmin.php:36
msgid "Feature Code Admin"
msgstr ""

#: page.featurecodeadmin.php:39
msgid "Use"
msgstr ""

#: page.featurecodeadmin.php:39
msgid "Default"
msgstr ""

#: page.featurecodeadmin.php:40
msgid "Feature"
msgstr ""

#: page.featurecodeadmin.php:40
msgid "Status"
msgstr ""

#: page.featurecodeadmin.php:68 page.featurecodeadmin.php:91
msgid "Disabled"
msgstr ""

#: page.featurecodeadmin.php:90
msgid "Enabled"
msgstr ""

But we can see on ./admin/config.php?type=setup&display=featurecodeadmin more messages, then listed (and could be translated) in xgettext. This is: Call Pickup ChanSpy? Dial System FAX Simulate Incoming Call User Logoff User Logon ZapBarge? Info Services Call Trace Directory Echo Test Speak Your Exten Number Speaking Clock Check Recording Save Recording Voicemail Dial Voicemail My Voicemail etc.

If you can see the amp.po - you can see this messages and correct translates.

if what I did works, it expects to find the translations for each set of feature codes in the modules that provide the feature codes. So if you have translations for paging feature codes for instance, they would need to be their. One possible bug (if what I did even works) is that core doesn't get its feature codes from core/i18n but from admin/i18n. But you could do the following and report back what the results are:

ln -s /var/www/html/admin/i18n /var/www/html/admin/modules/core

beyond that - I am very acknowledgeable about the translation subsystem and we are waiting for a developer who has a vested interest in the localization system to step up to the plate and get involved with the project to review what we have in place and then help enhance/change/fix it so that it works properly throughout as well as coming up with a better way to get new and changed translation files into the system without having to update every module each time.

We have translated featurecodeadmin.po > featurecodeadmin.mo, have added into /var/www/html/admin/modules/featurecodeadmin/i18n/ru_RU/LC_MESSAGES near with he_IL and it_IT translations, but Feature Codes still cannot translated. Only several words - Status, Default, Core, Call Pickup is translated to this 3 language, not for all. FreePBX 2.4.0rc1.1 + Asterisk 1.6.0beta2

bumping to next milestone, can backport if appropriate.

whats the status here?

from my testing and the current infrastructure localization infrastructure, it does not look like this is fixable. I'd love to be proven wrong but for now it is deferred until we make some arch changes to the localization infrastructure.

r6580

in it's current state if you put the translations with the featurecode module. Still working to get it so the translations can be with each contributing module but at least this now proves to work better than before.

(In [6581]) re #2461 these changes make it appear to finally work. If the translation files for a featurecode are in the module that provides the feature codes, it seems to pickup the translations there, if it does not find them there, then it appears to pickup the translatino from featurecodeadmin and if not there, it seems to pick them up form the amp.po file, making it capable of using tranlations's that have been put in all the different places in the past but in the future, allows them to be housed with the hosting module

Rigt said, Phillip.

For all who were following this bug, please review and provide feedback to: #3166

(In [6582]) re #2461 this change will do the gettext from the module's domain, if they have a domain and the string is not translated, then it would not otherwise translate it, so it checks if the translation is the same as the original string and if so, it attempts using _() which will check featurecodes and amp domains (which otherwise happens if there is no domain for the target language defined)

(In [6584]) re #3166 and re #2461 the remove the linefeed that the xml parser inserts before and after an ampersand in menuitems and catagories so that translations can have a better chance of matching

(In [6585]) re #3166 and re #2461 also cleanup the name field

(In [6586]) re #3166 and re #2461 fixed typo in variable

(In [6587]) re #3166 and re #2461 added translations to Module Admin so it can get them out of module's i18n also

(In [6590]) re #3166 and re #2461 added ability to translated description and attention module admin xml fields