New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support ruby/rails i18n yml files #3248

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

Comments

Projects
None yet
6 participants
@brauliobo

brauliobo commented Feb 10, 2015

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 https://github.com/nijel/weblate/issues/645

@unho

This comment has been minimized.

Show comment
Hide comment
@unho

unho Feb 10, 2015

Member

Not yet planned.

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

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

This comment has been minimized.

Show comment
Hide comment
@brauliobo

brauliobo Feb 10, 2015

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

brauliobo commented Feb 10, 2015

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

@unho

This comment has been minimized.

Show comment
Hide comment
@unho

unho Feb 10, 2015

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@jleclanche

jleclanche Feb 10, 2015

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.

Member

jleclanche commented Feb 10, 2015

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

This comment has been minimized.

Show comment
Hide comment
@brauliobo

brauliobo Feb 10, 2015

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

brauliobo commented Feb 10, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@jleclanche

jleclanche Feb 10, 2015

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.

Member

jleclanche commented Feb 10, 2015

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

This comment has been minimized.

Show comment
Hide comment
@brauliobo

brauliobo Feb 10, 2015

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

brauliobo commented Feb 10, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@dwaynebailey

dwaynebailey Feb 10, 2015

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.

Member

dwaynebailey commented Feb 10, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@brauliobo

brauliobo Feb 11, 2015

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

brauliobo commented Feb 11, 2015

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

@rvanlaak

This comment has been minimized.

Show comment
Hide comment
@rvanlaak

rvanlaak 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'

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

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

nijel added a commit to nijel/translate that referenced this issue Sep 21, 2016

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

nijel added a commit to nijel/translate that referenced this issue Sep 21, 2016

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

This comment has been minimized.

Show comment
Hide comment
@nijel

nijel Sep 21, 2016

Contributor

I've just made PR for this: #3500

Contributor

nijel commented Sep 21, 2016

I've just made PR for this: #3500

nijel added a commit to nijel/translate that referenced this issue Sep 21, 2016

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

nijel added a commit to nijel/translate that referenced this issue Sep 21, 2016

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

nijel added a commit to nijel/translate that referenced this issue Sep 21, 2016

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

nijel added a commit to nijel/translate that referenced this issue Oct 3, 2016

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

@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