1.0.0

[karellm]

Roadmap for the release:

• Rewrite helpers
• Write a Lexer per supported language
  • HTML
  • Handlebars
  • JS
• Write a parser that auto-detect the file extension and call the proper Lexer
• Update CLI code
  • Transition to vinyl-fs
  • Compile ES6 code
  • Test cli
• Bugs and other
  • Make sorting an option Do not sort keys #74
  • Make indentation an option Allow indentation level to be specified as a cli parameter #75
  • Remove gulp-util
  • Update lexers options
  • Fix defaultValue bug i18next-parser applying wrong translation value from original locale files #43
  • colon in key Problem with : (colon) inside text #67
  • Better error handling (PluginError?)
  • YAML output yaml output? #61
  • Create context keys (see this)
• Update the documentation
  • CLI
  • Gulp
  • Write transition document

Roadmap post release:

• Track file path Tracking file path references for each key #55
• Write a Lexer for JSX Doesn't extract keys from Interpolation component with react-i18next #57
• Add documentation Grunt/Webpack
• Handle arrays/objects in catalog
• useKeyAsDefaultValue

Other

• Prettier
• Coveralls

[immortal-tofu]

Since you rewrite many things, take a look at prettier. It's a great tool to clean up code. Just add .prettierrc and use their binary or VSCode/Atom plugin.

[karellm]

@birdy- thanks I will definitely look at it. My code style changed quite a bit in the last 4 years, every time I had to maintain that code base was an humbling moment 😄 The new structure will hopefully make that a lot more pleasant.

As to opinionated code styles, they make sense until they don't and then get in the way. That said I definitely should configure a linter of sort for collaborators to know what rules to follow.

[tkrotoff]

I have a suggestion: generating JS files (e.g locales/fr/translation.js). We would then have comments:

{
  // Extracted from file src/utils/Colors.js
  "Red": "Rouge",
  "Orange": "Orange",
  "Yellow": "Jaune",
  "Green": "Vert",
  "Blue": "Bleu",
  "Indigo": "Indigo",
  "Violet": "Violet",

  // Extracted from file src/utils/Languages.js
  "English": "Anglais",
  "French": "Français",

  // Extracted from file src/SignUpForm.js
  "First Name": "Prénom",
  "Last Name": "Nom de famille",
  "Email": "Email"
}

It's nice for the translator to have the "context", like gettext's PO files:

#: lib/error.c:116
msgid "Unknown system error"
msgstr "Error desconegut del sistema"

[karellm]

@tkrotoff My understanding is that #55 would address that. Is there something more you'd want?

[tkrotoff]

@karellm thx for the link. #55 proposes to use JSON, that's better than my proposition that relies on JS comments: you can then easily extract paths with a tool if needed.

[immortal-tofu]

Prettier will format code with few option (max length of a line, simple/double quote, ...). It's great because you don't have to do it manually.
Prettier is not a eslint --fix because it won't change anything in your code. It means, if you use a let instead of a const or do some useless import, it won't change it.
So prettier is not "enough", you have to use a lint. Since airbnb-eslint is not "compatible" with prettier out of the box, you can extend your rules with airbnb and prettier to solve incompatibilities. https://github.com/prettier/prettier-eslint

If you need help or you want me to setup it, I can do it.

[karellm]

It's almost there. 1.0.0-beta1 is coming very soon!

[karellm]

@birdy- I won'd use prettier because it transforms:

if() {
}
else {
}

into

if() {
} else {
}

which makes absolutely no sense to me.

[immortal-tofu]

By far the biggest reason for adopting Prettier is to stop all the on-going debates over styles.

:D

[karellm]

Well there is something more important than rigidity. It's consistency, readability and actual productivity while coding. Prettier doesn't score well in the last 2 for me.