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)
Firefox OS Graveyard
Gaia::First Time Experience
ARM
Gonk (Firefox OS)
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)
People
(Reporter: nhirata, Unassigned)
References
Details
(Keywords: l12y, Whiteboard: l10n, LocRun1.3, LocRun1.4, locRun2.0, LocRun2.2, LocRun2.5)
Attachments
(1 file)
91.47 KB,
image/png
|
Details |
## 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 :
Reporter | ||
Updated•11 years ago
|
blocking-b2g: --- → tef?
Whiteboard: l10n
Comment 1•11 years ago
|
||
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)
Comment 2•11 years ago
|
||
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)
Updated•11 years ago
|
blocking-b2g: tef? → -
Comment 3•11 years ago
|
||
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)
Comment 4•11 years ago
|
||
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)
Comment 5•11 years ago
|
||
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).
Reporter | ||
Comment 6•11 years ago
|
||
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
Comment 8•11 years ago
|
||
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
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
Comment 10•11 years ago
|
||
(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…
Comment 11•11 years ago
|
||
Also seen on Leo version 20130411070205 Kernel Date: Mar 15 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/f671fa539473 Gaia: e7e338a765e22334b40ced41489a785941382c66
Comment 13•11 years ago
|
||
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...
Comment 14•11 years ago
|
||
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)
Comment 15•11 years ago
|
||
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)
Comment 19•11 years ago
|
||
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.
Comment 20•11 years ago
|
||
I don't think we should block on this. Axel do you agree?
Comment 21•11 years ago
|
||
(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.
Comment 22•11 years ago
|
||
Peter, I guess we should find out the priority here and go from there.
Flags: needinfo?(pdolanjski)
Updated•11 years ago
|
blocking-b2g: koi? → 1.3?
Updated•11 years ago
|
blocking-b2g: 1.3? → 1.3+
Comment 24•11 years ago
|
||
This shouldn't be blocking+ until product confirms this is a 1.3 blocker.
blocking-b2g: 1.3+ → 1.3?
Comment 25•11 years ago
|
||
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)
Comment 26•11 years ago
|
||
(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)
Comment 27•11 years ago
|
||
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)
Updated•10 years ago
|
Whiteboard: l10n → l10n, LocRun1.3
Updated•10 years ago
|
Whiteboard: l10n, LocRun1.3 → l10n, LocRun1.3, LocRun1.4
Updated•10 years ago
|
status-b2g-v1.3:
--- → affected
status-b2g-v1.4:
--- → affected
Comment 29•10 years ago
|
||
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)
Updated•10 years ago
|
status-b2g-v2.0:
--- → affected
Whiteboard: l10n, LocRun1.3, LocRun1.4 → l10n, LocRun1.3, LocRun1.4, locRun2.0
Updated•10 years ago
|
Updated•9 years ago
|
Whiteboard: l10n, LocRun1.3, LocRun1.4, locRun2.0 → l10n, LocRun1.3, LocRun1.4, locRun2.0, LocRun2.2
Updated•9 years ago
|
Whiteboard: l10n, LocRun1.3, LocRun1.4, locRun2.0, LocRun2.2 → l10n, LocRun1.3, LocRun1.4, locRun2.0, LocRun2.2, MGSEI-l10n-1F-Arabic
Updated•9 years ago
|
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,
Comment 35•9 years ago
|
||
[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?
Comment 36•9 years ago
|
||
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)
Comment 37•9 years ago
|
||
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)
Comment 38•9 years ago
|
||
(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.
Comment 39•9 years ago
|
||
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.
Comment 40•9 years ago
|
||
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)
Comment 41•9 years ago
|
||
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)
Comment 42•9 years ago
|
||
[triage] not priority for v2.5
Updated•9 years ago
|
blocking-b2g: 2.5? → ---
Comment 44•9 years ago
|
||
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
Updated•9 years ago
|
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
Comment 46•6 years ago
|
||
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.
Description
•