Get Localization

[apeisa]

Might be worth testing for us: http://www.getlocalization.com

[petsagouris]

Another (huge) one is Transifex

But the bad thing is that none actually support the format for the translations that Processwire uses:

• File formats on transifex
• File formats on getlocalization

[ryan]

Looks like getlocalization supports JSON and transifex supports YAML. It would be fairly easy to convert to/from formats they recognize. 

[petsagouris]

I'd like to add that in Transifex there are "resources" (the master language files) that may be set up to be fetched periodically from a public repository making the upadting of the strings inside those resources a non issue for the developers.

[apeisa]

Oh yes, quickly tested these and Transifex is very very cool.

I tested it with adminbar strings, I made it to this:

en_US:
  site--modules--adminbar--adminbar-module:
    translations:
      1b9abf135ccb7ed2f2cd9c155137c351: "Browse"
      7dce122004969d56ae2e0245cb754d35: "Edit"
      03c2e7e41ffc181a4e84080b4710e81e: "New"
      0323de4f66a1700e2173e9bcdce02715: "Log out"
      e3afed0047b08059d0fada10f400c1e5: "Admin"
      5f0ab45d8140d117f4c5dd9e45286107: "Page is locked"
      5a1680fd738b22b7c0a8191373985ac8: "No rights to edit"
      a46d5c11c00d0d1df7504e10b8f6da3e: "%s moved to trash."
      2049f18f9d75ff92438a31f97b58311d: "%s was saved succesfully."

And what it gave to me was super cool editing interface. Free for open source too. It seems to me that this would be superb tool compared to current way with github and json.

How much work it would be to get that kind of YAML out from source files Ryan?

[petsagouris]

Provided that the LanguageParser inside Processwire can parse a file and identify the translatable strings I believe that it would be fairly easy to get all the files parsed and have the resulting files dumped in a folder in any format. It would be best to have that invocable (http request or commandline) since it may or may not be a heavy operation run only sporadically in development.

[ryan]

It would probably be quite easy to go between the current file format and another, especially another JSON/YAML type file. Our current file format is very simple. I'm not totally clear on the format that would be required by Transifex though. I'm also not sure I fully understand the value of these services since they can't parse the PHP source files for translation strings? Maybe I need to get in there and play. 

[apeisa]

Create an account on transifex and I add you into a project. It seems to be a very nice tool for doing translations in collaboration.

Translations are easiest way for many people to "give back", and current way isn't very easy to get started. In github model you don't even see the original strings, which makes it clumsy.

I think that tool like Transifex would lower the barrier to contribute and manage translations.

[ryan]

Sounds good. My account name is processwire. Though I've not received their activation email yet, so not sure my account is active. 

[jtherczeg]

Though this topic is old enough, let me pick it up again.

I also encourage you to move the localization to Transifex.

From the view of translators, it is amazing that the translated strings are stored in translation memory, so in the case of an update a translator needn't start his job from scratch, but can leverage the already existing translations. Additionally, it supports team work, so multiple translators can apply for the translation of a project, adding reviewer privilege for the best translators, the quality assurance may be provided.

In the case of multiple languages, the challenge of "who is faster" may motivate your translators to complete a job as soon as possible - a kind of international competition.

[Ivan Gretsky]

There is Pootle in case we decide to have our own solution for that. But Transifex seems to be popular. Some Joomla projects were on Transifex. I would sertanly join the Russian translation group whichever way gets chosen.

[jtherczeg]

There are a couple of online translation/localization tools, free for open source projects. I think it would be worth to investigate them and choose one.

[Christophe]

Pootle seems interesting: pootle.translatehouse.org + translatehouse.org/products.html

[Martijn Geerts]

One little point:

There's a lot of `console.log` going on. Somehow there's in my mind that that could break processing of javascript in old versions of IE. (Maybe i'm wrong) Never the less I want to mention it 

Posted this to the wrong post. Hell yeah, I like tabs in browsers

Edited September 5, 2014 by Martijn Geerts

[Pierre-Luc]

If work's done to start using Transifex or whatever, I'll be glad to dig in and produce a French translation for the whole PW.

[Ivan Gretsky]

I have registered to Transifex and found Ryan's & Apeisa's ProcessWire project. As I can see, there is only some sample data there. Russian language has been requested but the request has not been accepted.

@Ryan & @Apeisa: Could you please write about have you found transifex suitable to generate processwire-style translation files. Do you plan on using this service to maintain translations? If so, could you please import all the strings necessary or delegate this to someone from us, the community.

[Christophe]

Hello,

Would it be (technically) possible/difficult to have a Processwire native language pack automatically created based on the official git repository files, and also updated automatically or from time to time to see the changes/additions more easily?

I'm often not satisfied with parts of French translations in CMSs and would prefer to have a native file(s) pack to start from.

NB: I know I can always change later the parts that I would like translated differently, but it's good to have a (complete) reference in the native language in the same form as the language packs.

[Christophe]

Hello,

I've just been wondering what the French language pack (and other language packs) - at https://www.transifex.com/projects/p/processwire/ - is compatible with.

With which version(s) of Processwire is it (fully) compatible? And "how" to (easily) follow with language updates as there are more and more frequent updates to the core?

(Are the transifex versions Processwire 2.5.x (compatible) versions?)

Thanks in advance.

Have a nice week!

NB: if not, I guess I'll have to translate from Spanish - haven't practiced for a long time -, or learn German as it's language pack is more up to date (as there is no English/American/native language pack in order to have a "better" translation).

[jtherczeg]

Hello, Christophe!

The PW translation project on Transifex is obsolete.

PW has an "in-house" developed Language Translator module for translating the files, having the advantage of to be able to test and proofread your job on the fly. I highly recommend you to read the Language Translation Updates blog post.

This tool can detect the blank lines and the abandoned ones in a language file, this helps your job in updating a translation file.

BTW, if you browsed Modules Directory / Language Packs, you might find the French language pack for PW 2.2.

[Manfred62]

Hi Christophe,

if you want to do some french translation you can take the existing lang files and compare them with the list of files from this thread. In the stable PW 2.5.2 we have 122 files for translation. For the new dev there are 3 more files. If you want, you can also start from scratch with the empty files of the mentioned thread.

The existing fr lang pack is a little bit old. Not sure if the authors stopped working with? You can try to contact them.

[Christophe]

@jtherczeg: (if the PW translation project on Transifex is obsolete it should be deactivated, shouldn't it?)

I had seen quickly the Language Translation tool, but it didn't seem very convenient. I'll take a look at it again.

The French language pack for PW 2.2 seemed to old for me to start from.

@Manfred62: I had read the thread you're mentioning, and written in it, as you may have already seen.

Perhaps because I haven't really had the opportunity to try it and also the internal translation tool, I had/have the impression that it is easier to start from an existing language pack (Spanish, German...) than from an empty one. Surely, in part, because in empty files it seems "complicated" to (know how to) modify the files from a text editor.

[Manfred62]

hi Christophe,

I think it's better to translate inside PW instead of working with a text-editor. It's not perfect to work with, but doable.

See the image. If you upload empty files, you will get all translatable strings as empty inputs.

Example: 'Template' is empty, because it's the same word in german. 'Created' will be translated with 'Erstellt'.

Imho best practice: take the existing french files, compare filenames with the empty-pack. Some files will not be used anymore. Then put the rest of the fr-files in the empty-pack (replace the same filenames). At the end you should have 122 files (for stable PW). Upload them and start translating.

[lisandi]

I would like to recommend POOTLE

http://pootle.translatehouse.org/?id=pootle/index

Simply setup a subdomain http://translation.processwire.com
install pootle here

invite the complete community to help translating all files in the core and modules.

It is a real community approach and it ensures high quality to.
 

and it is very easy to handle!

If you want to see how this looks like on a professional enterprise CMS than check it out here:
http://translation.typo3.org/

add your own 2 letter language code and directly you get to your language.
You can see immediately what translations are still needed.

i.e.
http://wiki.typo3.org/Translation#Using_Pootle

here you can find a short tutorial and description on how to use Pootle.
To make cooperation easier there is a Translation Terminology Project which ensures that things get named constantly the same way when building extensions.
Standardization of the Translation you could call it!

Setup a Team Page where you can inform about Teams and their members which do those translations or which actually manage also the access and ensure that translations get reviewed.
http://wiki.typo3.org/Thai-Translation-Team

We translated TYPO3 4.5 LTS 100% in 2010 but since than as you can see lots of words have already changed again in the core so we are working on the translation of TYPO3 6.2 LTS now.
http://translation.typo3.org/th/

usually we do this with our Interns. It would be nice to see Processwire also in Thai Language.
But translating it in the way you are doing it right now is a real hazzle and takes lots of time and does not at all allow collaboration.

I think you could learn a lot from how TYPO3 is utilizing Pootle for all translations.
Beside this the translations of Modules and core get loaded separately after installation. They also get updated from within TYPO3 which for sure would be also possible inside Processwire as you can update core and modules already why not also translations.

As all translation files get stored on the translation server, the modules with their english default language file (some provide already some other languages from start) are kept free from not needed ballast. Best would beactually to make it a rule that all modules need to have the default in English like the core and that all other translations get stored and managed on Pootle.

---
And it is getting even better with the upcoming release
http://docs.translatehouse.org/projects/pootle/en/latest/developers/roadmap.html

---
In General I would recommend to keep all language translations in a separate file. This usually also reduces hard coded stuff as developer get used to use translatable variables instead as also the default English Language would be in a separate file.

site/module/abcdefgh/abcdefgh.module
site/module/abcdefgh/locallang.xml
site/l10n/de/abcdefgh/locallang.xlf
site/l10n/de/abcdefgh/locallang.xml






 

[Christophe]

Pootle had been mentioned earlier this year (see page 1).

[lisandi]

Yes christophe you are absolutly right and I read it but since than absolutely nothing has happened beside the fact that you now can list all translateable files in the backend. Unfortunately this is only usefull for local translation stuff, which means for a soecific translation for one specific customer i.e. He wants to call a specif term with another word that his customer wishes to have,

But for real good and especially for translations in a professional style Pootle is the cheapest and best solution IMHO. We use it at TYPO3 since several years now. also here they had another solution before which did not have all those benefits from a collaborative tool like Pootle.

After your post on page 1 you can see already people posting that they are interested to help and for sure there will be many more if Pootle gets installed for that translation purposes.

The problem right now is that lots of terms inside those php files are still hard translated which is not usable at all for a multilingual CMF. Therefore I suggested already to introduce localization files. Those could be xml / xlf and are very easy to translate and to use in the php files too.

Until now there isn't actually not such a huge amount - in comparison i.e. What we have at TYPO3 - what would need to be traslated and what would need to be modified so that a localized translation file gets used. it could even be a continouus process similar to what we did at TYPO3 where also lots of stuff was originally spread all over inside the PHP in other php files in xml etc. This chaos ended with Pootle and since than also the number of people contributing to the translations increased as everybody can see and suggest.

What would be needed.

1 setting up pootle on a server. We could do that, and get http://translation.processwire.com connected to that installation. IMHO it is good to keep stuff at processwire.com.
2 the core would need to be modified so that it will use separate translatable files for each language.
3 those files can than be translated as a collaborated work on Pootle http://translation.processwire.com
4 the same you could start in parallel with all modules.
5 finally all translatable files would be accessible on http://translation.processwire.com and everybody could check the current state and contribute to it either as a suggestion or as a team member
6 we would organize translation teams in processwire. i am pretty sure that we will find enough people to manage and review those translations and building localisation teams. With Pootle i.e. i would build up a team hee to get Processwire running 100% in Thai and I am pretty sure that my friend in Hongkong would help translate it to Kantonese and I have someone who could do the same for vietnamese and Chinese and probably even Italian and other languages. I am living here on a multicultural and multilingual innovation Paradise Island (phuket) and lots of IT profs and those who like to be one are here working legally and many illegally from here, or bali (Indonesia). This all will happen as soon as a Pootle installation would be available with the first translatable files of Processwire.
7 translating processwire is also a great way to make it more accessible to people who don't speak or can't read English Language. Even many think that English is the Lingua Franca we should not underestimate that far more people not even can read English letters!!! And among them are great developers! As there languages are pretty much organized like a programming language. I.e. With some Indian Langauges exactly this is the case.

I see no problem to get the following Languages organised and up and running in Translation Teams

Russian - see page No. 1
French - see page No. 1
German - there is already a great team - without good collaborative tool
Thai - we will do that here
Kantonese - friend in Hongkong also TYPO3/DRUPAL/ODOO/PROCESSWIRE Web agency

With the following we can help to get it running due to our connections and the interest in Processwire
Chinese simple
Vietnamese
Khmer
Vietnamese
Bahsa Indonesian
Burmese
Some indian languages
Spanish - i read that there was also somebody already willing to help
...
...

The only thing what would be needed is a collaborative Tool! And Pootle is simply the best as you know what is going on, because you are managing it yourself and the system itself is free - well it needs some server space but this is not at all a problem!

By the way usually than you will have even an swiss or austrian translation team beside the German one as some terms are simply (very) different in swiss German etc. with pootle that is absolutly no problem.

If than anybody would like to have his special terms in a soecific site, than we can modify the already integrated tool in the backend which lists all those language files and he can customize his terms for a specific site but even than won't loose the possibility to update all his languages any time when core or a module gets updated.

The update mechanisms integrated in the great module Manager would need to be modified to take care of that. In other words at any time something gets updated you also would get the newest versions of your translated files which fit to the module.

Very good in Pootle is that you can build up a standardized Terminlogy and even Specify terms which should not get translated i.e. Processwire itself the name.

Have a look to the http://translation.typo3.org and check out the features. You can see the number of terms which would need to get translated. a progressbar shows you with one view where help is needed. Our interns i.e. Have to work on those translations all the time when they have nothing else to do. Works just perfect and keeps them away from destructing things like facebook. And they are actually even proud and happy to make it accessible for the thai people.

Perhaps some know say again that they should learn English - well they are doing that but as you can't tell all non programers and visitors of a website to learn English first we have to translate the terms into their languages. The translations cover frontend and backend translations.

A standardized terminology will help also to automate some stuff in templates you have to set up, so that they pull the right language and no translation of terms would be needed in template files.

If than still some insist to do all locally and are not willing to collaborate than it is their problem and they can still do that without harming the progress of processwire translation teams.

Let me know when we can start, Please!

By the way if you want to keep everything the json way than there is also way with Pootle

As Pootle does not allow Json files you could modify yor local version of Pootle to read JSON files - I won't do that as it will increase workload in maintaining the installation.

The better way to use a conversion tool to po files instead and convert the translations back to Json later This process of coverting the po files back to json files could be done while importing and updating translations to processwire.

The converter which is doing both ways is already existing as GNU GPL2 and therefore integratable into Processwire.
http://translate-toolkit.readthedocs.org/en/latest/commands/json2po.html

json2po [options] <json> <po>

this would be needed if a new module gets uploaded to the translation server

po2json [options] -t <json> <po> <json>

this would be needed to import the translated PO files into any processwire installation around the world.
I am pretty sure that Nicos tool could be adjusted to import those files correctly including the conversion back from po to json files.

Those sceptical could try out the translation tool with some existing files and check!
 

The process would be like follow:

1. The developer is creating his module on his local machine
2. Like said earlier it woudl be great to have a place to gather all those developments i.e. http://forge.processwie.com which would be connected to a git repository
3. From there there could be language requests and than a module language file gets uploaded to pootle or this repository would get scanned regularly for new language files.
4. Those language files get converted into po files and then be usable for translation in Pootle
5. All translation files get stored and managed there
6. If a new translation gets added to a processwire installation anywhere in the world the (adjusted) language import tool what nico has build would pull a new translation from Pootle - converting the files back from po to json and uploading them to the right place in that local installation.
7. If now a new translation gets added or an existing gets modified there need to be a tool - could be again the one of Nico or the module manager and upgrade manager, which actually checks regularly with the updates made on Pootle. If there is a new one available it woudl suggest to download that new translation and /or even would show what has been changed or added.
8. Using the build in translation manager the site owners or admins ould still be able to adjust the translations to individual needs. Perhaps it would be good to name those modified files than a bit different and check if such a modified is existing and if not the default (the one downloaded from pootle) gets used. Terms modified in the locally modified file would overwrite those downloaded from pootle but not destroying them. This would reduce the workload for many of us who have to deal with multilingual sites all the time and would still enable people to use individual terms too.