YAML support

[TheRusskiy]

Pretty much what the title says.
I find YAML format to be way more readable.

Based my changes on initial pull request by "cjroth"

• Fixed failing test (cjroth changed API to use "json" instedad of ".json"
• Added test for passing .yml to config
• Minor readme / message changes
• YAML locale example
• Found bug that if locale.js exists it overrides any locale.json and locale.yml (with extension passed explicitly)

I see that you are running tests against many node.js versions on Travis ci, inluding 0.8
It can cause issues since I used "fs.existsSync", which, I believe is a part of new API.
Anyway... CI will show. If bad things happen I'll revert to using old fs.statSync.

[TheRusskiy]

Sigh...
Runs fine on 0.9 and 0.10, but still dies on 0.8.
Can't reproduce on my machine even with the exact same version =(

Btw, in travis CI you also use 0.9 version, but it says:

$ nvm use 0.9
N/A version is not installed
default -> v0.10.12
$ node --version
v0.10.12

Well... To be honest I have no freakin idea what the hell is wrong with CI 0.8 version.
Like I said it works on my machine so If you don't mind I will delete this test I wrote.
If someone else encounters similar issue with YAML we will at least have local computer and be able to debug.
Change doesn't break existing code and works fine on newer versions.

[mashpie]

Will review thanks for contributing :)

Von meinem iPhone gesendet

Am 03.11.2013 um 19:28 schrieb Dmitry Ishkov [email protected]:

Sigh Runs fine on 0.9 and 0.10, but still dies on 0.8

—
Reply to this email directly or view it on GitHub.

[nick4fake]

Sorry, when do you plan to review this? YAML is superior for translations.

[mashpie]

in fact I still need to check with some newer features like dot-notation that could be affected by this one

[highfeed]

I did not understand
YAML supported?

[breezewish]

+1 for yaml support. My locales were reverted and everything were lose several times only because I misplaced an extra , in the end of a row, which made the json invalid :(

[PavelPolyakov]

+1 for the yaml support, or extending the locales load method, so developer can pass his own.
For now I don't see such option.

[nickbuddendotcom]

+1

[gustavohenke]

Yay, almost 3 years and this is still not merged 😁

[mashpie]

That's the deal with priorities

Am 04.10.2016 um 03:16 schrieb Gustavo Henke [email protected]:

Yay, almost 3 years and this is still not merged 😁

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[gustavohenke]

Is there anything I could help with, @mashpie?

[mashpie]

well I guess, conflicts are hard to resolve now. So e fresh PR adding that feature would be most usefull, including tests & docs.

[augnustin]

Well for those who don't want to wait for the PR to be merged, I wrote another translation module: https://github.com/aug-riedinger/i18n-node-yaml

I used a different approach: files organised by content instead of by language. You get:

# translations.yml

hello:
  world:
    en: Hello World
    fr: Bonjour le monde
foo:
  bar: Foo bar

instead of having both:

# en.yml
hello:
  world: Hello World
foo:
  bar: Foo bar

and

# fr.yml
hello:
  world: Bonjour le monde
foo:
  bar: Foo bar

Here are the immediate advantages I get:

• No need to duplicate if word is international/not translatable (eg. foo.bar)
• 1 single file to edit when tree structure moves (and it regularly does)
• Visually obvious which translations are missing
• Instant evaluation of the necessity to translate (eg. English Contact will do at first then will be translated by Kontact in German eventually)
• Super easy to translate : the original source is only 1 line above! No need fancy software to do that.
• Files are organized by content, not translations

Looking forward to having some feedback on this.

[hishammalik]

+1

[jun85664396]

+1

[jesobreira]

My PR #358 may be related to this.

[mashpie]

so... although not merged directly - will keep as todo for refactored backend project