Deprecate PluralForm.jsm and migrate to use mozIntl.PluralRules

RESOLVED WONTFIX

Status

()

P3
normal
RESOLVED WONTFIX
2 years ago
a year ago

People

(Reporter: gandalf, Unassigned)

Tracking

({dev-doc-needed})

Firefox Tracking Flags

(Not tracked)

Details

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

2 years ago
Depends on: 1270146, 1215247
(Reporter)

Comment 1

2 years 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

2 years ago
What is proprietary in PLuralForm.jsm?

Will it be finally possible to use plural forms infrastructure from c++ code?
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

2 years 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

2 years 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.
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

2 years 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

2 years 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!
Priority: -- → P3

Comment 9

2 years 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
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

2 years 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.
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
that does not make much sense anymore.
Status: NEW → RESOLVED
Last Resolved: a year ago
Flags: needinfo?(jfkthame)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.