Deprecate PluralForm.jsm and migrate to use mozIntl.PluralRules

NEW
Unassigned

Status

()

Core
Internationalization
P3
normal
11 months ago
11 months ago

People

(Reporter: gandalf, Unassigned, NeedInfo)

Tracking

({dev-doc-needed})

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 months ago
Now that PluralRules API landed (bug 1270146), assuming it'll stick, we can start migrating away from proprietary PluralForm.jsm toward it.

The only thing to be careful is that we can't migrate android-related uses, since we don't have mozIntl.PluralRules on Android due to ICU.
(Reporter)

Updated

11 months ago
Depends on: 1270146, 1215247
(Reporter)

Comment 1

11 months ago
Jonathan, how should we approach this?

Should we mark PluralForm.jsm calls as deprecated? Migrate existing code is one thing, but I'd like to make sure that new calls don't use it.

Also, seems like an easy bucket to target first is DevTools since they are a major consumer of PluralForm.jsm and are not on android.
Flags: needinfo?(jfkthame)

Comment 2

11 months ago
What is proprietary in PLuralForm.jsm?

Will it be finally possible to use plural forms infrastructure from c++ code?

Comment 3

11 months ago
I think this is a no-go, as long as we're not welcome to refactor existing UI code for the sake of refactoring.
(Reporter)

Comment 4

11 months ago
(In reply to :aceman from comment #2)
> What is proprietary in PLuralForm.jsm?

It's basically our custom API. PluralRules is an ECMA402 proposal that we're hopefully get in JS 2018.
See: https://github.com/tc39/proposal-intl-plural-rules

> 
> Will it be finally possible to use plural forms infrastructure from c++ code?

So, in theory, yes.

I don't know if we tried it before, but the core functionality is available now from Intl.h:
https://hg.mozilla.org/integration/autoland/file/tip/js/src/builtin/Intl.h#l399

It may be that we'll want to have a thin-wrapper for this function.

But, we also would *love* to have you never ever need to use it from C++ :)

The new l10n infra that we'll be moving to will do the intl like plural rules for you for all localizations (deprecating .properties) so that leaves cases where you need Intl without L10n.
For those, I can imagine that being the solution.

I never wrote any C++ code calling to Intl.h APIs, but it should be totally doable.

You probably could also just use ICU calls directly. :jfkthame, already on NI? may be a better person to recommend which approach is better.
(Reporter)

Comment 5

11 months ago
(In reply to Axel Hecht [:Pike] from comment #3)
> I think this is a no-go, as long as we're not welcome to refactor existing
> UI code for the sake of refactoring.

We're migrating away from all of our custom Intl code to ICU/ECMA402 backed where possible. I would assume that this falls into the same bucket.
Doing it is a major goal for the Intl team in H1 2017.

Comment 6

11 months ago
The Intl team doesn't have stakes in this, really. Exposing localizable strings in yet another format is something that got rejected, and we should respectful of that.
(Reporter)

Comment 7

11 months ago
I didn't suggest exposing localizable strings in yet another format, irrelevant of if I agree that that's what got rejected.
(Reporter)

Comment 8

11 months ago
Oh, rereading the thread I see where I misrepresented my intentions. To summarize:

 - I'd like to figure out how to prevent new uses of plural form that doesn't use l10n from happening
 - investigate if there is a way to seamlessly replace plural form to plural rules API as a backed to strinbundle plurals


Sorry for confusion!

Updated

11 months ago
Priority: -- → P3

Comment 9

11 months ago
dev-doc-info
PluralForm.jsm is currently described at https://developer.mozilla.org/en-US/docs/Mozilla/Localization/Localization_and_Plurals#Developing_with_PluralForm.

This needs to be adjusted once it is deprecated.

Sebastian
Keywords: dev-doc-needed

Comment 10

11 months ago
There doesn't seem to be any concrete proposal here on what to use instead of PluralForm.jsm and semicolon-separated string fragments inside a single string.

Note, the API is a tiny fraction of the work here, the real task is how to expose the strings to developers and localizers.
(Reporter)

Comment 11

11 months ago
I agree,

:sebo, the doc you pasted should just be removed once we're done deprecating (it will take some time).

What I would recommend documenting is the new api which landed in bug 1270146 and has the spec here: https://github.com/tc39/proposal-intl-plural-rules

I'd document it as if it was on Intl.PluralRules because that's where it will end up on. `mozIntl` is just a chrome-only place where we expose Intl APIs that we use internally before we're ready to expose them to the web content.

Comment 12

11 months ago
That API is nice to document, but it's not of practical use, outside of l20n. Note, bug 1270146 already has the dev-doc-needed keyword, which signals it as something to document.
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #11)
> :sebo, the doc you pasted should just be removed once we're done deprecating
> (it will take some time).

Ok, good.

> What I would recommend documenting is the new api which landed in bug
> 1270146 and has the spec here:
> https://github.com/tc39/proposal-intl-plural-rules
> 
> I'd document it as if it was on Intl.PluralRules because that's where it
> will end up on. `mozIntl` is just a chrome-only place where we expose Intl
> APIs that we use internally before we're ready to expose them to the web
> content.

Thank you for the info!

(In reply to Axel Hecht [:Pike] from comment #12)
> Note, bug 1270146 already has the dev-doc-needed keyword, which
> signals it as something to document.

Correct. And Zibi (and other developers), please, please add the dev-doc-needed flag when filing or commenting on a bug, which requires documentation. That would help the MDN team a lot.

Sebastian
You need to log in before you can comment on or make changes to this bug.