Skip to content
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

Plural support in JSON files [$50 awarded] #1572

Closed
wichert opened this issue Jul 20, 2017 · 13 comments
Closed

Plural support in JSON files [$50 awarded] #1572

wichert opened this issue Jul 20, 2017 · 13 comments
Assignees
Labels
enhancement Adding or requesting a new feature. translate-toolkit Issues which need to be fixed in the translate-toolkit
Milestone

Comments

@wichert
Copy link
Contributor

wichert commented Jul 20, 2017

I find myself needing plural support in JSON format. I am pretty flexible about which toolkit to use, so I don't quite care if that uses i18next or MessageFormat format.

The i18next syntax is the simplest of the two and looks like this:

{
   "key": "You have {{count}} item.",
   "key_plural": "You have {{count}} items"
}

For languages with multiple plural forms the key format is key_# for fixed-number strings, and key_plural for other numbers.

The ICU MessageFormat format is more powerful, and thus more complex. While it is interesting, I expect it would require a massive UI change to support properly.

@nijel I'm happy to set a bounty for this. Can you give an indication of what would be needed?

@wichert
Copy link
Contributor Author

wichert commented Jul 20, 2017

Thinking about this a bit more I don't think a UI to unpack all ICU MessageFormat options makes sense. It is probably better to show the message as-is, and require translators to understand the format. Combined with a verifier to detect transform structure differences (perhaps based on pyseeyou ? ) that can be workable.

That suggests two possible paths:

  1. Support i18next plural support
  2. Add an ICU MessageFormat verifier

@nijel
Copy link
Member

nijel commented Jul 20, 2017

Having support for i18next seems easily doable, but I have one remark to that: This is not a correct way to handle plurals, many languages have more complex rules than just having singular and plural. So when you consider starting with plurals I'd suggest using something what can handle this.

ICU MessageFormat looks quite close to what l20n is doing and it's turning translators to a programmers because with all features the translations can get quite complex. On the other side I think most of the features will not find much use...

@nijel nijel added enhancement Adding or requesting a new feature. translate-toolkit Issues which need to be fixed in the translate-toolkit labels Jul 20, 2017
@wichert
Copy link
Contributor Author

wichert commented Jul 21, 2017

The i18next format does support more than just singular and plural. Here is the example for Arabic with five plural forms:

{
  "key_0": "zero",
  "key_1": "singular",
  "key_2": "two",
  "key_3": "few",
  "key_4": "many",
  "key_5": "plural"
}

There is a test tool on the i18next plural page that will dump the keys for each language for you.

From a purity point of view I do like the ICU MessageFormat for its accuracy, but you are completely correct that it forces translators to become programmers which is likely to lead to problems. Especially when you have to use translation agencies who use their own tooling and people who you can't train properly. From a more practical point of view the i18next format seems a lot easier to manage, and I highly doubt I'll ever need the extra flexibility the ICU MessageFormat offers.

@nijel
Copy link
Member

nijel commented Jul 21, 2017

Ah, I didn't notice this. So in the source there will be key and key_plural, while in translations key_[0-5]? That looks pretty confusing, but can be handled...

@wichert
Copy link
Contributor Author

wichert commented Jul 21, 2017

I think that is correct.

Would setting a bounty on this help getting it in the 2.16 release?

@nijel
Copy link
Member

nijel commented Jul 21, 2017

The implementation would (probably) be in the translate-toolkit only so it's more depending on their release schedule. As for Weblate 2.16, it will be pretty much feature frozen today...

@wichert
Copy link
Contributor Author

wichert commented Jul 21, 2017

I'm still waiting for them to make a release with the nested JSON support as well :). Still, if a bounty would result in this being implemented for translate-toolkit soon we can temporarily use a private release as well.

@nijel
Copy link
Member

nijel commented Jul 21, 2017

I can't promise much from my side in next three weeks (next week I have vacation and then I'm at DebConf starting with 4th August).

@wichert
Copy link
Contributor Author

wichert commented Aug 12, 2017

I've added a bounty to this ticket.

@nijel nijel added the bounty label Sep 1, 2017
@nijel nijel self-assigned this Sep 1, 2017
@nijel nijel added this to the 2.17 milestone Sep 1, 2017
@nijel
Copy link
Member

nijel commented Sep 1, 2017

The pull request on translate-toolkit is here:

translate/translate#3678

As usual, Weblate will need just small glue, which I will add soon.

@nijel nijel closed this as completed in 05c5bb1 Sep 1, 2017
@ghost
Copy link

ghost commented Nov 29, 2017

@nijel
I've noticed that exporting into i18next JSON files is not working properly.
This works the same when code is being pushed to repository.

Each form instead of having separate key is put into subarray under original key.
Subarray has ordinal keys.

So my initial english

{
  "hello": "Hello",
  "apple": "I have an apple",
  "apple_plural": "I have {{count}} apples",
  "apple_negative": "I have no apples"
}

in polish exports to

{
  "hello": "Witaj",
  "apple": [
    "Mam jabłko",
    "Mam {{count}} jabłka",
    "Mam {{count}} jabłek"
  ],
  "apple_negative": "Nie mam jabłek"
}

instead of

{
  "hello": "Witaj",
  "apple": "Mam jabłko",
  "apple_1": "Mam {{count}} jabłka",
  "apple_2": "Mam {{count}} jabłek",
  "apple_negative": "Nie mam jabłek"
}

is it possible to fix it ?
or could you point me into source so I could try working on it myself,
although I'm not familiar with python.

@nijel
Copy link
Member

nijel commented Nov 29, 2017

I can't reproduce this. I've just added test to translate-toolkit to cover this scenario and it works as expected: translate/translate#3748

Anyway, can you please open new issue for that so that we don't mess up existing one?

@ghost
Copy link

ghost commented Nov 30, 2017

Thanks for quick answer.
Sorry, yes, I've created new issue #1701.

@nijel nijel added this to TODO in File format support Jan 30, 2018
@nijel nijel changed the title Plural support in JSON files Plural support in JSON files [$50 awarded] Mar 5, 2018
@nijel nijel moved this from TODO to Done in File format support Mar 23, 2018
@nijel nijel changed the title Plural support in JSON files [$50 awarded] Plural support in JSON files May 3, 2018
@nijel nijel changed the title Plural support in JSON files Plural support in JSON files [$50 awarded] May 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Adding or requesting a new feature. translate-toolkit Issues which need to be fixed in the translate-toolkit
Projects
Development

No branches or pull requests

2 participants