1311666 - Rename OS to PLATFORM

Status: RESOLVED FIXED

(L20n :: JS Library, defect)

Description

[Staś Małolepszy :stas]

The name 'OS' is too specific because it strictly means an operating system, whereas there's value in differentiating between desktop environments on Linux for example.

I suggest we rename it to PLATFORM and return one of:

  windows, macos, gnome, unix.

Comment 1

[Zibi Braniecki [:zbraniecki][:gandalf]]

what about android/ios?

Comment 2

[Staś Małolepszy :stas]

Yeah, so the list would be:

  windows, macos, gnome, unix, android, ios

where 'unix' is a general name returned if the DE is not Gnome.

Comment 3

[Zibi Braniecki [:zbraniecki][:gandalf]]

I'm in favor of this change.

Do you see a path forward where we may want to also distinguish between flavors? If, say, we'd want gnome vs kde? And is there any other platform that has similar variety of flavors that may have different localization patterns and we'd may want to distinguish between them or is it only a linux thing?

Like, ps4, xbox etc. would be PLATFORMs, right?

Comment 4

[Staś Małolepszy :stas]

Great questions.  Since we're dealing in the matters of translation it makes sense to assume that the platform to us is a set of translation guidelines unified under a common name.

That's why I'd suggest we add "gnome", "unity", "kde" and possibly "xfce".  I even wonder if "unix" is helpful or could it simply be folded under "other" -- what do you think?

> Like, ps4, xbox etc. would be PLATFORMs, right?

I think so!

Comment 5

[Axel Hecht [:Pike]]

Maybe this is something that needs to work like PLURAL?

I.e., OS() would return a thing, that matches "unix" and "gnome"

Comment 6

[Zibi Braniecki [:zbraniecki][:gandalf]]

> I.e., OS() would return a thing, that matches "unix" and "gnome"

The problem here is that we're dealing with three potential "levels" in the scope of our current work:

1) XP_WIN / XP_MACOS / XP_UNIX
2) XP_GNOME

which is defined as XP_UNIX && !XP_MACOSX

3) MOZ_WIDGET_GTK

which can returns a version (2 vs 3)

============

There is also:

4) platform: http://searchfox.org/mozilla-central/source/toolkit/modules/AppConstants.jsm#

which can be linux, win, macosx, android, gonk or other.

5) MOZ_WIDGET_TOOLKIT

which can be cocoa, windows, gonk, gtk2, gtk3, android, ios, uikit

6) MOZ_X11
7) XP_LINUX

Comment 7

[Zibi Braniecki [:zbraniecki][:gandalf]]

There are several interesting challenges:

1) XP_UNIX and XP_LINUX are true on linux
2) XP_UNIX and XP_MACOSX are true on macos
3) MOZ_WIDGET_GTK can be non-false on any platform
4) XP_GNOME AND XP_LINUX AND XP_UNIX will be true often

I'm wondering if we should try to clean up this mess. If so, I'd suggest we do:

1) PLATFORM: linux, win, macosx, android, ios, unix, other
2) WIDGET_TOOLKIT: cocoa, windows, gtk2, gtk3, android, ios, uikit, other

That should hopefully be enough.

Thoughts?

Comment 8

[Staś Małolepszy :stas]

A few thoughts:

 - thanks for doing the research on these preprocessor's variables;  this looks indeed quite complex,

 - we should not lose track of the goal which is to give the localizers the ability to adjust translations to the HIG of the current UI,

 - the information about the widget might be more of an implementation detail and I'm not sure if it's helpful to expose it to localizers; what would be the use-cases for it?

 - cleaning the mess up is a risky endeavor and likely to introduce regressions;  if we want to clean it all, I suggest we not block bug 1291693 and land this later,

 - would just implementing PLATFORM returning one of (linux, windows, macos, android, other) be helpful right now?  I didn't include ios on the list b/c of macos, watchos and ios converging into a single thing.  I also removed unix, which would need to mean both linux and macos.  if yes, then let's do it; if not, let's wait until after we've landed the menubar in FTL in m-c.

Comment 9

[Zibi Braniecki [:zbraniecki][:gandalf]]

>  - we should not lose track of the goal which is to give the localizers the ability to adjust translations to the HIG of the current UI,

There are different "HiG" levels. You can follow "linux" convention, or "gtk" convention (which is very similar to "gnome" but different than "kde").

>  - the information about the widget might be more of an implementation detail and I'm not sure if it's helpful to expose it to localizers; what would be the use-cases for it?

GTK3 enforces some decisions on accesskeys which means that we have to special-case GTK3 compared to other widget toolkits.
That's why I suggested two built-ins.

I agree that it's risky, but if we agree on the general direction, I could land just the PLATFORM one and try to see how much I can safely migrate. We can then leave the rest to post landing.

Comment 10

[Axel Hecht [:Pike]]

I wonder if we should try to convert as much as possible. That sounds like "making it complex where we can" instead of "making it possible where we have to".

I tend to think of things like ja-JP-mac as use cases. And there were others, too, where just in one locale, that thing was different on that platform. Or the choice of accesskeys on a platform require that other one to move a bit to the side in one localization.

I'm not convinced that implementing things that are platform-dependent at large in the localization is a win for our communities :-/

Yeah, that's more of a revelation I just had.

Comment 11

[Staś Małolepszy :stas]

The way I understood Zibi's question was: what constitutes a "platform"?  How granular do we want the PLATFORM built-in to be in FTL?  When you say "that thing was different on that platform" -- how would you define different platforms?

(In reply to Axel Hecht [:Pike] from comment #10)
> I wonder if we should try to convert as much as possible. That sounds like
> "making it complex where we can" instead of "making it possible where we
> have to".

I'm afraid I don't understand this.  Can you try to rephrase, please?

Comment 12

[Axel Hecht [:Pike]]

So there are two scenarios to contrast:

We have a series of strings that have a OS() selector expression in basically all locales.
We have a series of pairs/triples with simple values in the string, which have no selector.

I think I prefer the latter.

As to platform, I really think we need to make that a "smart" string, that can match to multiple tags at the same time. Otherwise we'd break all existing uses each time we're forced to add another variant for yet another of UI niches.

Comment 13

[Staś Małolepszy :stas]

Oh, I think I understand now!  When you said:

   I wonder if we should try to convert as much as possible.

That actually meant that you had doubts rather than suggest that we should :)

> We have a series of pairs/triples with simple values in the string, which
> have no selector.
> 
> I think I prefer the latter.

OK, I think I agree that in Firefox it's safer to go with the latter.  I'd like to continue thinking about this when we start adding new strings and start shipping other projects with l20n.  E.g. in websites, I'd prefer using PLATFORM() to doing the platform detection in JS and setting a platform specific l10n-id ('open-settings-windows').  Also because I expect websites to need that much less often.

> As to platform, I really think we need to make that a "smart" string, that
> can match to multiple tags at the same time. Otherwise we'd break all
> existing uses each time we're forced to add another variant for yet another
> of UI niches.

Yeah, I like that idea, and it also makes me think that we should wait; first ship l20n and then land this later on as an incremental improvement.

Comment 14

[Staś Małolepszy :stas]

If we do go with the latter (series of per-platform simple-string pairs/triples), we could remove the OS() builtin altogether from the gecko bindings. Less code! :)

Comment 15

[Staś Małolepszy :stas]

(And then add PLATFORM() with extended matching semantics.)

Comment 16

[Zibi Braniecki [:zbraniecki][:gandalf]]

Attachment: pr

Comment 17

[Zibi Braniecki [:zbraniecki][:gandalf]]

Landed https://github.com/l20n/l20n.js/commit/1a988184a2c41e4b378602235e3697ce9bdbea45

Comment 18

[Staś Małolepszy :stas]

Zibi, can you land this on larch as well, please?

Comment 19

[Zibi Braniecki [:zbraniecki][:gandalf]]

https://hg.mozilla.org/projects/larch/rev/6e3ca667d606d35930d24bb0235946cade494812
Bug 1311666 - Rename OS to PLATFORM. r=stas