Attachment added by ncouture on 41278843-06-23: french-language-pack-for-176.zip

ewinslow wrote on 41279101-06-16

Elgg moved away from gettext at 1.0. I suspect there's little motivation to go back.

brettp wrote on 41280201-01-20

There are some reason to consider it:

• None of the current devs made that decision.
• I don't buy the [http://docs.elgg.org/wiki/Engine/Internationalisation#Internationalisation reasons it was removed](too slow, unreliable).
• There are hundreds of tools for gettext to help translators. There are maybe 2 partial plugins to help Elgg translators.
• BOMs are a huge problem in UTF8 PHP translation files.
• The interface with elgg_echo() can be kept 100% the same if we want, so changes will be mostly transparent to plugin authors.

Milestone changed to Long Term Discussion by cash on 41959371-01-07

ewinslow wrote on 42248249-12-18

tl;dr: Let's write a php script that converts our format to PO and back.

I'm trying to come up with a way to get the best of both worlds here. The fact is that the php files intimidate non-developers, but thinking about .pot, .po, gettext tools, scripts, etc. was all very foreign and intimidating to me as a php dev. I would love to not have to worry about any of that. In fact, I don't think I even want to worry about maintaining translations with my plugin. I just want to make an update, provide the english wording for any new language keys, release it to the community, and let the people who care enough to get it translated make that happen. I don't want my plugin blocked on waiting for translations to come in -- those should be able to come in after I release and still be accessible to community admins who want them.

In order to take advantage of all the tools out there, I think one thing is clear -- we need to get PO files to translators, not PHP files. Instead of adopting gettext, we could just write something that converts an Elgg language mapping into a POT formatted file. A translator can then download the POT file from the community site, translate using whatever tool they feel most comfortable with, and then submit the resulting PO file to the plugin's community page. That PO file is then parsed and converted back into Elgg's PHP format. In order for these conversions to happen, there needs to be some persistence of the language key in the POT comments which elgg recognizes and can parse out when the translation is uploaded again.

Those downloading plugins can select which language files they want to include with the plugin download, and these will be included in the appropriate location. Either that or we can just include all of the translations by default and have a mechanism for admins to whitelist which languages their site supports.

And I'm sure we can come up with some way to handle new releases and ensure that people don't abuse this system for spam and whatever else.

as we are now using transifex, do we still need to do something related to this ticket?

Nope. Still wouldn't want to move to gettext anyways.