I really missed the support for ruby/rails i18n yml format. Do you have any milestone planned to support it?
Example file: https://github.com/noosfero/noosfero/blob/master/config/locales/en-US.yml
Issue first opened at WeblateOrg/weblate#645
Not yet planned.
If you only need a converter to PO format you can rely for now on https://github.com/unho/yaml2po
@unho could you please indicate the code where a translation backend is defined?
@brauliobo The repository I pointed to is only a set of converters from the Ruby YML translation format to Gettext PO and back. No translation backend is provided nor used there.
The format looks insane to be honest.
Not to complain about Ruby's NIH syndrome but I don't see what benefit it gives over the more usual formats such as PO and what not.
@unho actually I asked about the backends code on translate, not on yaml2po.
@jleclanche a very basic benefit is to use keys instead of hardcoding texts into code. this way, the english translation can also be edited.
another benefit: no compilation required.
another benefit: keys can be constructed dinamically on code.
another benefit: don't need to extract strings from code.
The source translation, in systems such as po, is "untranslated", it's not "english". English can be translated from untranslated, and generally that is what happens automatically. So if you want to have specifics going into your en_us or en_gb, there's no issue with that.
As for the other two benefits, there's plenty of formats that already offer that.
Anyway, if you want to contribute a converter, a good starting point is the json converter. I confirmed with the team that it should work pretty much the same.
@jleclanche the thing is to remove translations from code, so you can edit all text outside the code and don't need to extract translations from source code.
nice! could you link the code from the json converter?
@jleclanche lets not debate the merits of one format over the other. The toolkit was always designed to allow translators to work well with random formats and convert them to more sensible/proper localisations formats that their localisation tools actually do understand.
@brauliobo as you can see we have very strong opinions on why some of these formats are broken for localisers and all your reasons benefit only programmers and actually make it hard for localisers. Our priority is the make localisers productive and to warn away coders from the NIH where they solve their problems (which have often been solved before) and end up making it harder for their localisers. And trust me, it's a sea of that errors out there.
@brauliobo backend code in translate for storage support is in translate/storage, with converters in translate/convert. Landing such code would firstly give a converter and secondly can be used by other users of the toolkit such as Pootle. I would suggest that the json convertor and store might be a good place to look if you wanted to help get this onto our roadmap.
@dwaynebailey It is completely not a ruby NIH, this pattern of creating keys for translations instead of justing putting the untranslated (english) version is a trend in my opinion. I think it makes things easier for translators as they can change user interface texts (not only the translations) without touching a line of source code.
@dwaynebailey nice, I see for example https://github.com/translate/translate/blob/master/translate/storage/jsonl10n.py which looks pretty similar to Ruby i18n yaml files. But I don't understand why the converter was suggested. Is it necessary to implement support for a new format? I'm willing to work on support ruby i18n format for the Weblate translation tool, so Pootle is not the goal here.
Big 👍 on supporting the yml format, especially the nesting features of yml are great.
title: 'Page title'
heading: 'Page heading'
column1: 'Column 1'
column2: 'Column 2'
column3: 'Column 3'
Added YaML support
There are two classes to support two different YaML formats:
YaMLFile : generic key/value format
RubyYaMLFile : Ruby format with target language as root node
Added YAML support
There are two classes to support two different YAML formats:
YAMLFile : generic key/value format
RubyYAMLFile : Ruby format with target language as root node
I've just made PR for this: #3500