Support ruby/rails i18n yml files #3248

Closed
brauliobo opened this Issue Feb 10, 2015 · 12 comments

Projects

None yet

6 participants

@brauliobo

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

@unho
Member
unho commented Feb 10, 2015

Not yet planned.

If you only need a converter to PO format you can rely for now on https://github.com/unho/yaml2po

@brauliobo

@unho could you please indicate the code where a translation backend is defined?

@unho
Member
unho commented Feb 10, 2015

@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.

@jleclanche
Member

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.

@brauliobo

@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.

@jleclanche
Member

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.

@brauliobo

@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?

@dwaynebailey
Member

@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.

@brauliobo

@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.

@nijel nijel referenced this issue in WeblateOrg/weblate Mar 4, 2016
Closed

Check for YML support #222

@rvanlaak
rvanlaak commented Mar 4, 2016

Big 👍 on supporting the yml format, especially the nesting features of yml are great.

page_key:
    title: 'Page title'
    heading: 'Page heading'
    table:
        column1: 'Column 1'
        column2: 'Column 2'
        column3: 'Column 3'
@unho unho added this to the 1.15 milestone Mar 6, 2016
@unho unho added the formats label Mar 9, 2016
@nijel nijel added a commit to nijel/translate that referenced this issue Sep 21, 2016
@nijel nijel 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

Fixes #3248
42d8af5
@nijel nijel added a commit to nijel/translate that referenced this issue Sep 21, 2016
@nijel nijel 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

Fixes #3248
773c3d8
@nijel nijel added a commit to nijel/translate that referenced this issue Sep 21, 2016
@nijel nijel 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

Fixes #3248
6ef794d
@nijel
Contributor
nijel commented Sep 21, 2016

I've just made PR for this: #3500

@nijel nijel added a commit to nijel/translate that referenced this issue Sep 21, 2016
@nijel nijel 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

Fixes #3248
4968653
@nijel nijel added a commit to nijel/translate that referenced this issue Sep 21, 2016
@nijel nijel 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

Fixes #3248
1ae9fe2
@nijel nijel added a commit to nijel/translate that referenced this issue Sep 21, 2016
@nijel nijel 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

Fixes #3248
fc636d5
@nijel nijel added a commit to nijel/translate that referenced this issue Oct 3, 2016
@nijel nijel 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

Fixes #3248
0d9bbf2
@unho unho added a commit that closed this issue Oct 3, 2016
@nijel @unho nijel + unho 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

Fixes #3248
2a1adbf
@unho unho closed this in 2a1adbf Oct 3, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment