Ticket #2571 (closed Feature Requests: fixed)

Opened 4 years ago

Last modified 3 years ago

Change in how language and translation could be handled

Reported by: mickecarlsson Assigned to:
Priority: trivial Milestone: Undetermined
Component: Languages / Translation Version:
Keywords: Cc:
Confirmation: Need Feedback SVN Revision (if applicable):
Backend Engine: All Backend Engine Version:

Description

The current situation about translating FreePBX is somewhat difficult. A proposal from me is to do a small rewrite of the code to be able to do a translation without a new submission of a module. The attached file is the blacklist module with my suggestion and language files.

Instead of having the English text in the module you replace that with a label. Today it is like _("Some text") but in the future it should be like _DEFINEDLABEL. In a separate file called en_US.php you have the text like this:

<?php
// English text
define("_BLACKLISTENTRY","Blacklist entry");
define("_BLACKLISTDELETED","deleted");
.
.
?>

And in the module you have a line like this:

include_once("en_US.php");

Or get the definitions from the cookie set by language. To translate to another language all you have to do is to copy the en_US.php file to for example se_SV.php and then translate all text in that file.

<?php
// Swedish text
define("_BLACKLISTENTRY","Svartlistade nummer");
define("_BLACKLISTDELETED","raderad");
.
.
?>

By doing this you can easy translate all text without change anything in the module code. If you add some new text with a new label, that label could easily be added to all other languages. If a label is missing from a language file it will simply print the label on the page, and you can easy see what labels are missing from the language file.

I hope that my suggestion make sense. I have attached the blacklist module file together with the English and Swedish file for you to test out.

Attachments

page.blacklist.php (3.6 kB) - added by mickecarlsson on 12/18/07 15:34:13.
The modified blacklist module file
se_SV.php (0.7 kB) - added by mickecarlsson on 12/18/07 15:34:45.
The Swedish language file
en_US.php (0.6 kB) - added by mickecarlsson on 12/18/07 15:35:00.
The English language file

Change History

12/18/07 15:34:13 changed by mickecarlsson

  • attachment page.blacklist.php added.

The modified blacklist module file

12/18/07 15:34:45 changed by mickecarlsson

  • attachment se_SV.php added.

The Swedish language file

12/18/07 15:35:00 changed by mickecarlsson

  • attachment en_US.php added.

The English language file

12/18/07 15:41:24 changed by p_lindheimer

  • confirmation changed from Unreviewed to Need Feedback.
  • version deleted.

have you looked at the i18n translation information to see how the system is setup. That is the preferred method. What we are looking for is a developer with an interest in this area to help improve or fix how it is currently handled (if necessary) in the current design, as well as to help design an infrastructure that will allow localization information to be updated without the need to publish every module that is effected, by every language change.

Most of the code is properly implemented with its strings ready to be translated (with the _("message") format, it just needs some cleanup for those areas that are not, and then the above changes.

12/18/07 15:43:46 changed by p_lindheimer

btw - I don't have a problem with driving toward defining all the strings in one place (as it clearly helps the translator to find what they need to translate), but the overall mechanism using the i18n gettext() subsystem is still preferred.

12/19/07 08:44:21 changed by mickecarlsson

Well, as I have translated almost 70% of th 2.3.x branch to Swedish I have struggled quite a bit to:

1. Run the find for each module directory.

2. Translate the text.

3. Run the msgfmt -v <module>.po -o <module>.mo for each module directory.

4. Test the translation, fix spelling errors, do 2 and 3 once again, and again etc.

That takes time, an incredibly amount of time.

And, when you release an updated module with new text I have to do the find and compile again.

That I find disturbing.

My suggestion does not need any find or compile, just copy the en_US.php file to for example it_IT.php and translate the text. Done, nothing more, nothing less.

If you update a module with new text, the new string are added last in the language file, easy to detect, copy, translate and you are done. You can even send out the strings to the translators for an update before the module release so that it is coordinated.

12/19/07 15:12:49 changed by pnlarsson

I can second this suggestion, XOOPS are using the same setup as mickecarlsson is pushing for, and it's so easy to translate. I did translate ARI to swedish at one time but it was a real pain. It might look prettier but it's not easy to work with. On the other hand - a change would need a total change of all translations...

From XOOPS:

if ( file_exists(XOOPS_ROOT_PATH ."/modules/mblogg/language/".$xoopsConfig['language']."/mblogg.php") )
    require_once XOOPS_ROOT_PATH ."/modules/mblogg/language/".$xoopsConfig['language']."/mblogg.php";
else
        include_once XOOPS_ROOT_PATH ."/modules/mblogg/language/english/mblogg.php";

12/19/07 23:54:55 changed by mickecarlsson

The same setup that i propose is the same as in PHPNuke and ZoneMinder?, both to which I have done some translation to in the past. Easy to translate and maintain. From PHPNuke mainfile.php:

function get_lang($module) {
	global $currentlang, $language;
	if (file_exists("modules/$module/language/lang-".$currentlang.".php")) {
		include_once("modules/$module/language/lang-".$currentlang.".php");
		}

12/20/07 13:27:09 changed by p_lindheimer

the discussion is good and welcome. I will stress though that it is going to take a lead developer to joint the team, review the language architecture and determine how we should change/modify it moving forward

12/21/07 12:34:54 changed by mickecarlsson

I someone would like to join the team, what is the estimate time frame for such a project? Should it be in place for 2.4? Or next sub release or for the 3.0 branch?

01/16/08 14:13:25 changed by mickecarlsson

Proposal is now on the wiki with code examples to try out: http://freepbx.org/trac/wiki/NewLanguageSystem

NOTE!!! It is for FreePBX 2.4 Beta 2.2

10/15/08 00:49:34 changed by mickecarlsson

  • status changed from new to closed.
  • resolution set to fixed.

With the new fw_languagepack this feature request is covered. There is no need to redo the language part. And that we now provide the .pot files for amp and all modules, it will help translators. Closing this ticket as solved. If there is a need to redo the language part a new Feature Request will be filed.