Closed Bug 833393 Opened 11 years ago Closed 6 years ago

[FTE]: Provide a way to translate city names

Categories

(Firefox OS Graveyard :: Gaia::First Time Experience, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v1.3 affected, b2g-v1.4 affected, b2g-v2.0 affected, b2g-v2.0M affected, b2g-v2.1 affected, b2g-v2.2 affected)

RESOLVED WONTFIX
Tracking Status
b2g-v1.3 --- affected
b2g-v1.4 --- affected
b2g-v2.0 --- affected
b2g-v2.0M --- affected
b2g-v2.1 --- affected
b2g-v2.2 --- affected

People

(Reporter: nhirata, Unassigned)

References

Details

(Keywords: l12y, Whiteboard: l10n, LocRun1.3, LocRun1.4, locRun2.0, LocRun2.2, LocRun2.5)

Attachments

(1 file)

Attached image screenshot
## Environment :
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/0e43266ca3c6
Gaia   1890022f3ca36108621a832f31ac5df8bf89a22e
BuildID 20130122070203
Version 18.0
Unagi

## Repro :
1. run FTE
2. switch language to Portuguese
3. go through FTE until you get to the Time 
4. select the drop down for Cities

## Expected :
1. the values in the drop down are in Portuguese

## Actual :
1. the values in the drop down are in English

## Note :
blocking-b2g: --- → tef?
Whiteboard: l10n
Translating all city names would be a big piece of work, and I’m not sure it’s worth it.

Axel, what do you think?
Flags: needinfo?(l10n)
We shouldn't do that now. It's 450 strings, which sounds pretty harsh for the return value. I wonder if we could generate some sort of overlay where localizers could overload the used names for cities they care for. But that sounds like v2 material.
Flags: needinfo?(l10n)
blocking-b2g: tef? → -
Daniel - this would represent a fairly large chunk of l10n work, something we'd like to avoid. Please re-nominate if you feel this blocks shipping the phone.
Flags: needinfo?(dcoloma)
Not a blocker, but...

- Can we check all the cities in the target countries are at least correctly displayed in the language used in those countries:
   * Spain, Venezuela and Colombia cities in Spanish
   * Brazil cities in Portuguese

- I have also spotted that Sáo Paulo is listed after "Swift Current" when it should be listed right after "Santo Domingo" 

- There are also a bunch of cities that are duplicated, e.g. Argentina/Buenos Aires and Buenos Aires.
Flags: needinfo?(dcoloma)
I've been playing with that idea in a different context, but that's going to stop working as soon as we hit non-latin script markets. Not sure if this works if we just apply the rule for latin-script languages? Not sure how hard it would be to recognize München as Munich. (http://de.wikipedia.org/wiki/M%C3%BCnchen with the l10n links to the side show a lot of variation for that one).
Looks like there's no way to translate this from l10n side without fixes on the gaia end: https://bugzilla.mozilla.org/show_bug.cgi?id=837468
making the summary more generic, and keeping this bug, as it has the rationale for the status quo.
Keywords: l12y
Summary: [FTE][pt-br] : The values in the cities drop down are not in Portuguese → [FTE]: Provide a way to translate city names
Keywords: smoketest
Unagi Build: Gecko-56fd784 Gaia-de3e5b9 
Date&Time: The values in the cities drop down are not translated according to the language previously selected. They are always shown in english. Both selecting FTU or Reset Phone option
(In reply to Fabien Cazenave [:kaze] from comment #1)
> Translating all city names would be a big piece of work, and I’m not sure
> it’s worth it.
> 
> Axel, what do you think?

(In reply to Axel Hecht (pto - April 2) [:Pike] from comment #2)
> I wonder if we could generate some sort of overlay where
> localizers could overload the used names for cities they care for. But that
> sounds like v2 material.

I would suggest adding the whole list, even if it is that big, with original names (not en ones) with a l10n note about and info that it's perfectly fine to leave it untranslated. KISS

And right now it is pretty bad…
Also seen on Leo version 20130411070205
Kernel Date: Mar 15
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/f671fa539473
Gaia: e7e338a765e22334b40ced41489a785941382c66
This still occurs as of today on Leo phone, v1.1 COM RIL
Gecko: a199b1109860
Gaia: 3e9090894daaa1c7f894a1dcc1026b21f889eadc
BuildID 20130618070211
Version 18.0

in shipping locales for v1.1...
Delphine, we don’t intend to localize these city names for v1.1 — see comment 2.

(In reply to Stefan Plewako [:stef] from comment #10)
> I would suggest adding the whole list, even if it is that big, with original
> names (not en ones) with a l10n note about and info that it's perfectly fine
> to leave it untranslated. KISS

 • if this becomes a leo+ requirement
 • if we can afford spending a few cycles to make sure it won’t bloat the Settings app
 • and if Pike is OK with that (this could be an issue for the l10n dashboards)

then I can implement this.
blocking-b2g: - → leo?
Flags: needinfo?(l10n)
We shouldn't make this leo+, we're string and feature frozen.

We should keep the keys simple and ID-like, and not try to do spaces and accents and all that jazz. The dashboard should be fine, but who knows how robust other parsers and serializers are that people use.
Flags: needinfo?(l10n)
Moving off for 1.2 consideration.
blocking-b2g: leo? → koi?
Not a smoketest blocker. Pulling keyword.
Keywords: smoketest
Looking at CLDR for input now:

404 names for zh-TW, 111 for de, 168 for es, and we're having some 454 entries.

I think we should just add an empty file with good comments to shared, and allow localizations to add strings they want to overwrite.

The dashboard is going to show them as obsolete strings, I might fix that at a later point. It get's us off the ground, though.

I'd suggest to allow overloads for the regions, and for the cities independently. I'd probably use the 'city' property as key.
Depends on: 913458
I don't think we should block on this.
Axel do you agree?
(In reply to Gregor Wagner [:gwagner] from comment #20)
> I don't think we should block on this.
> Axel do you agree?

I don't think that's my call.
Peter, I guess we should find out the priority here and go from there.
Flags: needinfo?(pdolanjski)
blocking-b2g: koi? → 1.3?
blocking-b2g: 1.3? → 1.3+
This shouldn't be blocking+ until product confirms this is a 1.3 blocker.
blocking-b2g: 1.3+ → 1.3?
In general, I'd say we wouldn't block on this.  We are actually in the process of evaluating if we can drop the time selection screen from the FTE since we have SNTP support in bug 874771.  This should allow us to accurately determine the time on behalf of the user.  UX will be weighing in on this.

If we go forward with removing that screen, the user will still be able to access this in the Settings, but it becomes much less important.  
Axel, if we do want to move forward with the approach that you describe, are there dependencies on certain product capabilities or would it be handled by l10n?
blocking-b2g: 1.3? → -
Flags: needinfo?(pdolanjski) → needinfo?(l10n)
(In reply to Peter Dolanjski [:pdol] from comment #25)
> Axel, if we do want to move forward with the approach that you describe, are
> there dependencies on certain product capabilities or would it be handled by
> l10n?

That'd be a gaia engineering task. We may need a "has(ID)" API in l10n.js. That could land on stas/gandalf if we took the change of the underlying l10n.js infrastructure from bug 914414. Right now, l10n.js is also owned by the gaia team.
Flags: needinfo?(l10n)
Alternatively, this may fallback on the idea we had for fallback city names:

localeCityName={[ $cityName ]}
localeCityName[new york] = Nowy Jork
localeCityName[paris] = Paryż
localeCityName[*other] = {{ $cityName }}

where * marks the default value used if no value matches.

If we don't want to introduce the default value in proprties format (which may be awkward) then we could use some macro magic to check if the key exists before deciding which one to use.

Stas, what do you think?
Flags: needinfo?(stas)
Whiteboard: l10n → l10n, LocRun1.3
Blocks: 938423
Whiteboard: l10n, LocRun1.3 → l10n, LocRun1.3, LocRun1.4
Clearing the needinfo as per an IRL conversation with Gandalf.  This currently has low priority.  If it's needed in the future, we can make changes to l10n.js that will make the approach from comment 27 possible.
Flags: needinfo?(stas)
Whiteboard: l10n, LocRun1.3, LocRun1.4 → l10n, LocRun1.3, LocRun1.4, locRun2.0
Whiteboard: l10n, LocRun1.3, LocRun1.4, locRun2.0 → l10n, LocRun1.3, LocRun1.4, locRun2.0, LocRun2.2
Whiteboard: l10n, LocRun1.3, LocRun1.4, locRun2.0, LocRun2.2 → l10n, LocRun1.3, LocRun1.4, locRun2.0, LocRun2.2, MGSEI-l10n-1F-Arabic
QA Whiteboard: [MGSEI-l10n-1F-Arabic]
Whiteboard: l10n, LocRun1.3, LocRun1.4, locRun2.0, LocRun2.2, MGSEI-l10n-1F-Arabic → l10n, LocRun1.3, LocRun1.4, locRun2.0, LocRun2.2,
[Blocking Requested - why for this release]:

Seems like this was dropped. Since we're past CC for 2.2, nominating this for 3.0 - in the case that this is still relevant in the upcoming release, which we still don't know much about
blocking-b2g: - → 3.0?
What would be the plan for this at this point? 
Also note, FTU app should share this with Settings, so this is as much a Settings bug as FTE one. 
We have a steady trickle of bugs on duplicated cities or outdate/uncommon names for cities in the timezone list - which would also be addressed here I think - by asking localizers to provide a list that makes most sense for that region and locale. And finding a way to overlay that in Gaia.
Flags: needinfo?(gaia-l10n)
Please don't randomly request needinfo and hope that I'll actually answer. Even after prodding to not do that.

I don't have any news on the technical implementation, this is still an edge case.

On desktop, we'd use filter.py, I guess. We should port that to gaia/l20n before we have bug 1165906 on track, though. Also not sure if that's a good idea to begin with.
Flags: needinfo?(gaia-l10n)
(In reply to Axel Hecht [:Pike] from comment #37)
> Please don't randomly request needinfo and hope that I'll actually answer.
> Even after prodding to not do that.

Agreed this is not a high-priority feature, and there is no specific deadline on finding an answer - this is true of 100s of bugs yet we aspire to resolve them one way or another. Meantime, I do think its reasonable to seek input on an issue. Bugzilla doesnt have fine-grained controls for the priority of a needinfo request, so I apologise for the nagging ni? How would you prefer I or engineering in general communicate a request to the l10n team (without knowing which member would be able to field it?) Cc on the bug, email? I cannot find you in person, and our timezones don't overlap much for chatting in IRC.
There is no such thing as a team alias that would get you traction on a needinfo, and I don't think we should try to create one. I think that mozilla's module ownership structure gives enough insight in this case, https://wiki.mozilla.org/Modules/FirefoxOS#Localization lists gandalf and stas.
Flagging Stas as per comment 39.
Stas: do you have any update/insight on this, and on how we should go forwards with this in future releases? (also, see comment 36)
Also, thanks for looking into this Sam!
Flags: needinfo?(stas)
We're close to landing shared/js/l20n.js (bug 1175260) which is the new iteration of the L10n API.  It also uses a subset of the L20n syntax which we'll keep extending it until it fully implements the L20n grammar.  At some point during this process we'll be able to use the approach from comment 27.

It's not feasible yet, but we're on a good path and the first step is close to landing.
Flags: needinfo?(stas)
[triage] not priority for v2.5
blocking-b2g: 2.5? → ---
The CLDR provides numerous translations for all the cities/locations in the Olson database, and also formats them correctly (so that "Indiana/Knox" becomes "Knox, Indiana"). So bug 1201237 would allow us to fix this bug without putting a huge burden on our translators (who are not geography experts).

Bug 1201254 might reduce the impact of this bug by reducing the importance of Olson cities in our UI. But we might still get an Olson city from the mobile network provider, or ask the user to select one for Daylight Saving purposes.
Depends on: 1201237
QA Whiteboard: [MGSEI-l10n-1F-Arabic] → [MGSEI-l10n-1F-Arabic], [MGSEI-l10n-2F]
Whiteboard: l10n, LocRun1.3, LocRun1.4, locRun2.0, LocRun2.2, → l10n, LocRun1.3, LocRun1.4, locRun2.0, LocRun2.2, LocRun2.5
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: