Could the translation files be stored in human-readable format?

[Robert Zelník]

I really like the translation interface. I just have some difficulties with reading the output files exported from the ProcessWire Languages interface. Currently the .json files look like this:

• the whole file is stored in a single line
  
• non-ascii/accented characters are encoded in \uXXXX format
  

This makes the translation file hard to read for human beings. Could be possible to implement line-wrapping and storing the text in UTF-8? I have read that UTF-8 is preferred for JSON files and I assume that the appropriate line endings would not make the file hard to read for the application.

[Soma]

Why? I've never had the feeling I need to edit them directly in the file.

Edit: Maybe something like this does help? http://www.jsoneditoronline.org/

[Robert Zelník]

You are right, we don't need to edit directly in the file, but the possibility to check the files can be useful for checking/comparing the changes, when more people collaborate on the translation etc.

The online JSON editor is great, thanks for the tip. I will use it.

[Soma]

Ah. Then are you using the translation for frontend template? I tried it once and got away from it for various reasons. I still use translation files for frontend translation (for the static terms, forms etc) using yaml file for each langauge. So it's much easier to compare and have them in a readable key -> value format. It allows me to define them like:

label_send:  Send
...

Then in templates I can use it like:

$txt['label_send'];

In the head I include and determine the langauge using this code:

require_once($config->paths->root . "site/libs/yaml/sfYaml.php");
require_once($config->paths->root . "site/libs/yaml/sfYamlParser.php");
$yaml = new sfYamlParser();
// parse language file
$txt = $yaml->parse(file_get_contents($config->paths->root . "site/languages/" . $lang . ".yaml"));

I use this php yaml parser lib https://github.com/fabpot/yaml

[Robert Zelník]

No, actually I work on backend translation.

[yellowled]

Why? I've never had the feeling I need to edit them directly in the file.

I actually did. Why? First of all, I prefer working with larger amounts of text or code in my favourite text editor over working in a web frontend any time. Second, using search/replace mechanism would've made it much easier to keep the translation consistent. There are quite a number of phrases in the translateable files which are used two or more times. (Which, by the way, is a bit inefficient.)

I ended up not using my favourite editor (which can handle .json files) because the language .json files are minified and apparently use some kind of escaping for special characters (like German umlauts). I didn't want to risk losing work over some weird side effects of using an editor.

[Soma]

Yeah, maybe it's not as ideal as one may wish it to be to enter translations. But it's pretty decent start. As I understand it, it's using gettext and it uses textdomain for each file/module in the context of it. This may seem inefficent, but one global file for all words used all over the system would be a nightmare. One phrase used in the context of a module may be differently translated in the context of another module in another language. Note also context information (descr) can be added right after the translation syntax, that will show in the translation editor. I think it's well thought out by Ryan, even though there's always things to improve. Maybe he also pops in to give his statement.

[Robert Zelník]

I agree with the idea of multiple translations for multiple contexts.

[ryan]

We use PHP built in JSON functions for speed and efficiency. PHP 5.4 adds two new options to json_encode for unescaped UTF8 and "pretty in print", so I think PHP 5.4 will solve this and I will implement a version check so

PW takes advantage of it.

[Robert Zelník]

Great news Ryan, thanks.

[yellowled]

I think it's well thought out by Ryan, even though there's always things to improve.

I never wanted to imply that there wasn't a good reason to implement it the way it is now, just why I would've liked the option to edit them in a text editor.