Support pluralization

[sokra]

https://developer.mozilla.org/en-US/docs/Localization_and_Plurals

__(count, ["one item", "#1 items"], "nItems").replace("#1", count)

{ // German
  nItems: ["Ein Element", "#1 Elemente"]
}

[necolas]

fyi: http://cldr.unicode.org/index/cldr-spec/plural-rules

[max-mykhailenko]

I will try to combine current loader with external solution http://i18next.com/pages/doc_features.html

[ronkorving]

That might be a great solution.

[max-mykhailenko]

@ronkorving It will be available on this weekends. Only small improvements left.

[ronkorving]

Are you saying you almost have a radically new version of i18-webpack-plugin ready? One that depends on i18next-node?

[max-mykhailenko]

@ronkorving Yes. Webpack generate bundle for each language using i18next-node. Static text already replaced completely as in current plugin but with additional i18next options. Plurals we must left as expression and replace dynamically on client side, Now I working on including language files and i18next module to the bundles. Unfortunately webpack doesn't has documentation for that.

[ronkorving]

Yeah, Webpack documentation on authoring plugins is very limited. I really appreciate your work on this, and can't wait to see the result! Thanks a lot, really.

[martyphee]

Is this being worked on anymore?

[max-mykhailenko]

@martyphee simple language bundles generation done, plurals must work only dynamic with i18next module. At this point I stop development of this feature. I can create gist with example

[martyphee]

Sure that would be great.

On Friday, January 22, 2016, Max Mykhailenko notifications@github.com wrote:

@martyphee https://github.com/martyphee simple language bundles generation done, plurals must work only dynamic with i18next module. At this point I stop development of this feature. I can create gist with example

— Reply to this email directly or view it on GitHub https://github.com/webpack/i18n-webpack-plugin/issues/1#issuecomment-174068500 .

[karlhorky]

@max-mykhailenko I'd also like to see a gist of this

[max-mykhailenko]

Sorry for delay https://gist.github.com/max-mykhailenko/64ce006f9febe4f0dbe6

[martyphee]

Thank you for the Gist. It's very helpful

On Wed, Feb 17, 2016 at 8:53 PM, Max Mykhailenko notifications@github.com wrote:

Sorry for delay https://gist.github.com/max-mykhailenko/64ce006f9febe4f0dbe6

— Reply to this email directly or view it on GitHub https://github.com/webpack/i18n-webpack-plugin/issues/1#issuecomment-185398203 .

[karlhorky]

Thanks for the gist. Are you planning on opening a pull request to add this to the plugin? Or do you have your own version of the plugin that you'll release?

[max-mykhailenko]

@karlhorky Actually I don't understand how I can combine json generating and webpack building process. Maybe it's loader for files .php .twig .js and than using I18nPlugin. I will appreciate if you help me with architecture if you have experience with that.

[karlhorky]

I'm not sure you need to generate the json yourself - that can be part of a different plugin, loader, etc. For instance, take a look at the i18n example. This plugin just reads in an existing json file.

---

I took a quick look at the plugin code, and it seems to me the correct way to go about it would be this:

1. Define a new function (maybe called ngettext?) near the top that will accept the arguments for plural translations. Maybe take inspiration from libraries like Jed
2. Define a new parser.plugin block to call the function and define behavior like the existing one.
3. Refactor: see if the existing parser.plugin function shares enough with the new function defined in the previous step that some of the code can be shared. Move any shared things out into their own standalone functions.

The question would be if i18next-node can help with step 2 or 3 above, or if the code would be simple enough that you just write your own implementation.

---

Or, @sokra @jhnns? Would this be a good way of doing it?

[karlhorky]

Alternately, the __() function could be reused (polymorphic based on the number and type of arguments passed to it). This is already being done here. Not sure if this would make the function do too much though.

[jhnns]

@karlhorky I think, the i18n plugin should support Jed style functions. Personally, I'd expect it to handle proper pluralization and contexts. Contexts are an important feature, because translations might be totally different based on the context they occur. That's probably something that native speaker tend to underestimate.

So, basically we should provide these functions:

gettext = function ( key )
dgettext = function ( domain, key )
ngettext = function ( singular_key, plural_key, value )
dngettext = function ( domain, singular_ley, plural_key, value )
pgettext = function ( context, key )
dpgettext = function ( domain, context, key )
npgettext = function ( context, singular_key, plural_key, value )
dnpgettext = function ( domain, context, singular_key, plural_key, value )

I know, the function names are kind of weird, but they are already well-known across different languages.

I think that should be doable with the current implementation. To simplify the implementation, that should probably be a breaking change.

[karlhorky]

that should be doable with the current implementation

So as to my proposal above, we would:

1. Define multiple new functions (along with keeping __() for backwards compatibility?)
2. Define parser.plugin blocks for each of them?
3. Refactor: In your opinion, could any of them share any code? Or is that what you meant by "breaking change"?

Would you leverage a library such as i18next-node or Jed for use in any of the plugin.parser functions or would you suggest we reimplement these functions ourselves?

[martyphee]

I would suggest i18next since it can handle more formats. Jed does work well. We currently use that.

On Fri, Feb 19, 2016 at 11:15 AM, Karl Horky notifications@github.com wrote:

that should be doable with the current implementation

So as to my proposal above https://github.com/webpack/i18n-webpack-plugin/issues/1#issuecomment-185642294, we would:

1. Define multiple new functions (along with keeping __() for backwards compatibility?)
2. Define parser.plugin blocks for each of them?
3. Refactor: In your opinion, could any of them share any code? Or is that what you meant by "breaking change"?

Would you leverage a library such as i18next-node or Jed for use in any of the plugin.parser functions or would you suggest we reimplement these functions ourselves?

— Reply to this email directly or view it on GitHub https://github.com/webpack/i18n-webpack-plugin/issues/1#issuecomment-186175787 .

[johannesnagl]

What's the status of this issue? Any progress since last year?

[mightyaleksey]

Hi, I made a small attempt to implement the dynamic keys: https://github.com/webpack-contrib/i18n-webpack-plugin/pull/42

I would like to have someone to look at it.