Staś Małolepszy :stas Reporter
	Description • 11 years ago

To differentiate between types of devices (phone, tablet, desktop), it would be useful to have a way to define variants of translations for each type.

For instance, the current "Device information" string might read "Phone information" on small-screen phones, and "Tablet information" on tablets.

I suggest we add this once we land the l10n.js refactor (bug 914414).  The refactor implements many concepts from L20n and modularizes the code, so we can add this with little effort.

As far as implementation goes, we could either implement this as what L20n calls "global variables" (http://l20n.org/learn/adapting-translations-to-current-time/), or as a macro (similar to the current plural() macro).  Let's discuss the pros and cons of each approach in this bug.

	Zibi Braniecki [:zbraniecki][:gandalf] Assignee
	Comment 1 • 11 years ago

I believe global variable will be better here since we have no input to process, just static data.

	Zibi Braniecki [:zbraniecki][:gandalf] Assignee
	Comment 2 • 11 years ago

I actually changed my mind. Because of the way we work in Gaia, I think it should be a macro provided by Gaia.

I'm working on a patch to add that.

	Zibi Braniecki [:zbraniecki][:gandalf] Assignee
	Comment 3 • 11 years ago

This patch adds a formFactor macro that allows for:

settings={[ formFactor() ]}
settings[mobile] = Settings Mobile
settings[tablet] = Settings Tablet

it currently always returns mobile, since I don't know do we want to identify tablet scenario.
I see several potential solutions:
 - resolution
 - aspect ratio
 - device name
 - some form factor API

Once we have dependencies landed this is going to be trivial to land.

	Staś Małolepszy :stas Reporter
	Comment 4 • 11 years ago

Nice work.  I think the more difficult part will be figuring out how to customize this on build time.  We might need some Makefile magic to change the return value of the macro.  Or, if the information about the device type is already stored somewhere, the macro could be made more agnostic and just query this other place.

	Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)
	Comment 5 • 11 years ago

(In reply to Zbigniew Braniecki [:gandalf] from comment #3)
> Created attachment 8334975 [details] [diff] [review]
> POC
> 
> This patch adds a formFactor macro that allows for:
> 
> settings={[ formFactor() ]}
> settings[mobile] = Settings Mobile
> settings[tablet] = Settings Tablet
> 
> it currently always returns mobile, since I don't know do we want to
> identify tablet scenario.
> I see several potential solutions:
>  - resolution
>  - aspect ratio
>  - device name
>  - some form factor API
>

From what I have been told people on the web determine that based on the width (using a virtual limit of 768px) and the orientation (landscape for tablet).

	Zibi Braniecki [:zbraniecki][:gandalf] Assignee
	Comment 6 • 11 years ago

(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #5)
> From what I have been told people on the web determine that based on the
> width (using a virtual limit of 768px) and the orientation (landscape for
> tablet).

that may work for UI, but we don't want to change the localization based on the orientation here.

awesome={[ formFactor() ]}
awesome[tablet] = Your tablet is awesome
awesome[mobile] = Your phone is awesome

I don't think we should select depending on the device orientation here.

As for resolution, that also sounds a bit risky to assume (and as we get more devices with higher DPI we'll have to change that?)

	gasolin@mozilla.com
	Comment 7 • 11 years ago

Please don't change the localization based on the orientation. Since once we have a ipod-touch-like device, and it will also be recognized as 'mobile'.

	chris hofmann
	Comment 8 • 10 years ago

it would be good to figure out this quickly, as asa's pushing to get a lot of tablet working going soon.

	Axel Hecht [:Pike]
	Comment 9 • 10 years ago

I'm concerned that the variable here isn't the right one. Like, http://recode.net/2014/02/06/our-love-affair-with-the-tablet-is-over/.

	Michael Henretty [:mikehenrty][:mhenretty]
	Comment 10 • 10 years ago

Is this still actively being worked on? We need something similar for bug 908300, but would love to rely on this if possible.

	Zibi Braniecki [:zbraniecki][:gandalf] Assignee
	Comment 11 • 10 years ago

(In reply to Michael Henretty [:mhenretty] from comment #10)
> Is this still actively being worked on? We need something similar for bug
> 908300, but would love to rely on this if possible.

There's a dependency here. Our toolchain currently cannot deal with string variants. I'll start working on that dependency (and file bugs) next week.

	gasolin@mozilla.com
	Comment 12 • 10 years ago

Our build system now able to pass GAIA_DEVICE_TYPE in. l10n could reference that type

# GAIA_DEVICE_TYPE customization
# phone - default
# tablet
# tv
GAIA_DEVICE_TYPE?=phone

defined in gaia/Makefile

	Staś Małolepszy :stas Reporter
	Comment 13 • 10 years ago

Thanks for the heads-up, Fred.  It looks like it could be very helpful indeed.

There were questions in bug 908300 about how this bug could solve sizing issues for localizations.  However, I think it is more about providing better UX for cases when you don't want to use a generic 'device' term and instead would prefer to use 'tablet' or 'phone' in the copy.

Sizing is a much more complex problem: screen size, resolution (dpi), orientation, installed fonts.  It's also much more language-specific, which is to say that where one language will be happy with a single-variant one-size-fits-all translation, another would like to be more granular and define a number of translations for different sizes. As Zibi explained in comment 11, this would currently not work with our infrastructure which relies on the fact that strings in properties files map 1-to-1 with en-US, including subvariants, and also would lack support from localization authoring tools, like Pootle and Transifex.

	Zibi Braniecki [:zbraniecki][:gandalf] Assignee
	Comment 14 • 10 years ago

Why did you alter the title of a bug in our component? This bug covers more than flatfish.

	Andrew Truong [:feer56] [:andrewtruong] [:atruong]
	Comment 15 • 10 years ago

Woops, sorry about that. I thought it would be easier to track for Flatfish. Most sincere apologies.

	BMO Automation
	Comment 16 • 6 years ago

Firefox OS is not being worked on