parameter handling for i18n helpers

[sylvainpolletvillard]

Hi !

It seems you decided to make more with this lib than just an experiment. Do you think the current approach and database structure could evolve to handle parameters ?

What I have in mind is some basic / commonly-used i18n helpers functions such as pluralization and date/number formatting. These helpers themselves can be very simple, for example a basic pluralization helper could be:

i18n.plural = declensions => n => declensions[n in declensions ? n : "_"]

count => `I have ${i18n.plural({ 0: 'no apples', 1: 'one apple', _: `${count} apples` })(count)}`

But I'm not sure how a template-string based approach could implement this, since it requires to do more than just parameter interpolation. Any thoughts about this ?

[WebReflection]

It seems you decided to make more with this lib than just an experiment.

it's the best approach to i18n I know so ... why not :wink:

for example a basic pluralization helper could be ...

that thing does not look right here ... old style, here it's about template literals

I'm not sure how a template-string based approach could implement this

it's easy, same exat way you'd do with non literals but you still use literals:

`I have ${count === 1 ? i18n`${count} apple` : i18n`${count} apples`}`

it's shorter, it gives you the ability to reuse that sentence about 0, 1, or more apples everywhere in your app (think about item/items) and it can be a shortcut in code:

const nApples = n => n == 1 ? i18n`${n} apple` : i18n`${n} apples`;

so that you do:

`I have ${nApples(count)}`

Sometimes you need to forget what you know to embrace a new pattern.

[WebReflection]

just FYI after latest babylon change it could be I need to fix nested i18n but that doesn't mean the way I've showed is wrong, it's just a glitch moving from Esprima delegate to babylon. Will check soon

[sylvainpolletvillard]

But languages have different plural rules. Some have 3 or more plural forms, and some don't even have a singular form, so the question was about moving the == 1 test in the translation instead of the app code.

[WebReflection]

The whole point of this library is that you write code and it translate transparently.

If you want to address all cases you write these bits:

i18n`one apple`;
i18n`zero apples`;
i18n`${n} apples`;

and the tools will generate all you need. This is all I've got for now.

If you have a better concrete proposal that looks right for a template literals based i18n then it's more than welcome but that initial proposal doesn't look right and you should drop biases from existent solutions because here key is KISS and YAGNI :wink:

[sylvainpolletvillard]

That would imply to translate all plural forms of all languages in any other language. I'm all for KISS, but very skeptical about YAGNI for this usecase. Anyway, I have my answer. Have a nice day

[WebReflection]

That would imply to translate all plural forms of all languages in any other language.

you write in one language and you can translate in one or many others

the client library is 10 LOC, you can extends as you wish but if you want to propose a different approach:

• you need to address the database structure
• you should provide a PR that brings your proposal to the utils
• you provide eventual changes to i18n-yummy too

Just open a bug with an idea is not enough to land here

[sylvainpolletvillard]

Sorry for the misunderstanding, I was not opening a bug nor asking for a feature. I'm just concerned about the long-term viability of the current approach for advanced i18n issues such as plurals, gender, dates etc. , and was curious about your opinion, that's all.

I wrote the piece of code in the initial post in a hurry, without much thinking into it, just to give you a quick example of what I have in mind when I say "when we need more than just parameter interpolation". I did not expect it to land or something. This is typically something I can build on top of your lib, but only if the internals allow it.

[WebReflection]

plurals, gender, dates etc. , and was curious about your opinion, that's all.

dates are a no brainer

// you write this in your code
i18n`Today is ${month}/${day}/${year}`;

// the utils lets you edit this
Today is ${0}/${1}/${2}

// which in italian, as example, would be
Oggi é il ${1}/${0}/${2}

About gender you have all the options you want, just use i18n`male` and i18n`female` or i18n`none-of-your-business` as options and you're good to go?

Internals are standard template literals. If you can deal with this constrain, you can do whatever you want on top.

I've created a whole new era of DOM parsing with them so the answer is yes, but you need to drop old-style i18n bias or we wont come up to a modern, template literals friendly, solution.

You want parameters? That's already doing it wrong 'cause tagged functions have already a pretty busy signature, all you can do there is bind a context, which might be an option.

But there's too much to discuss on this, and this library is just born and I don't want overengineer at day one, when there is already a 99% solution to pretty much all cases.

Feel free to bump with better proposals whenever you want, yuet this is not a bug so I'll keep it close for now.

[sylvainpolletvillard]

dates are a no brainer

lol sure, if you assume we all use Gregorian calendar and don't actually need any form of localization besides putting the month and day in the right order.

It seems you don't want to show the elephant in the room, so I won't bother anymore. Good luck with your new era !

[WebReflection]

the DOM parsing had nothing to do with this project, it was an example.

I don't understand why you need to answer like that but I have no time for this kind of contributors here so this is my first and very last invitation to behave.

take care of your i18n project