Right now, we only switching on the localization of gecko strings for es-ES, pl, pt-BR. On the gaia UI, we have cs, de, el, hr, hu, nl, ro, ru, sk, sr, tr in addition. Adding those to gecko will add a noticeable increase of disk space. I'd need an engineer to test and evaluate that. https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Building#Gecko has instructions on how to set up a build. If we need them, we can probably create patches for the localizations for those that have fennec localizations, the overrides are the same.
Created attachment 776320 [details] [diff] [review] Add 11 localizations to b2g's gecko Progress update: I've created patches for all 11 localizations, see the blocker bugs I filed for this one. Those are all with review requests on the community now. Most of those are shipping in Fennec, so little risk, but some are rather old non-shipping content. This patch would pick those up.
David, can you get me some help for the remaining tasks here? - test the patch - evaluate the impact of those 11 locales on things like image sizes etc. We'd need that to evaluate the risk of taking this patch in 1.1
* is this a regression from 1.0? * or are these new strings in gecko since 1.0? * what's the user impact? (ie, what are these strings?)
(In reply to Dietrich Ayala (:dietrich) from comment #3) > * is this a regression from 1.0? > > * or are these new strings in gecko since 1.0? This is new localizations starting to matter for 1.1, compared to 1.0. That had only 'es', 'pl' and 'pt-BR' on. > * what's the user impact? (ie, what are these strings?) error pages for dns, bad certs etc in the browser won't be localized, all the things that make the browser show the neterror.xhtml page. Also the slow-script dialog.
FWIW - From what I'm seeing from the dependencies here, it sounds like what Pike is describing here is porting over localizations we have on FxAndroid to Firefox OS for features that are in parity in FxAndroid to Firefox OS. Examples include the ones he mentioned - the certificate error dialog for example. If these are required 1.1 locales, then it makes sense to block on the related dependency work needed here for the required locales for 1.1.
Over to kaze as David is out We basically just need a review and evaluation of the image size impact.
Assignee: nobody → l10n
Flags: needinfo?(dscravaglieri) → needinfo?(kaze)
This is probably a silly question: what localized Gecko strings do we still need in Gaia? In a perfect world I think all localized strings would be defined in Gaia rather than in Gecko; and if we must keep a few Gecko strings, what exactly do we need in order to track them and include the bare minimum?
As discussed on IRC, I am uncertain if I understand this issue correctly. I believe that system app's responsibility is to replace any native gecko UI with HTML, and if we find that we still have some UI is shown from gecko, we should have a new API and let system app handle that in HTML/JS. The only exception is gecko's error page in browser app isn't handled by browser app but only shows the nsIError.xhtml I think Josh and Ben know the future plan. If we don't want to accept this gecko change we should figure out a way to display them before we have Fennec.
Axel, can you help with comment 8.
(In reply to Alex Keybl [:akeybl] from comment #9) > Axel, can you help with comment 8. Not much, sadly. The status quo is described in comment 4, and in all the bugs that this bug is blocking. If we could rewrite the neterror and cert error stuff to not need strings on the gecko side, I don't know. For a current gecko (not 1.8, that is), we can mirror what android does with bug 792077 and friends to cut down on the size impact. But the amount of regressions that had sounds like a good indication that we shouldn't try this in the 1.1 timeframe.
Marking NPOVB since it's a tracking bug.
blocking-b2g: leo? → leo+
I'm removing NPOVB again, as there's actually the code change in attachment 776320 [details] [diff] [review] in this bug to b2g/locales/all-locales that needs to land, and then all the dependent bugs should go away.
Any update on what we should do here?
This is getting really close to "not happening" at this point.
blocking-b2g: leo+ → leo?
Any update for this?
The "bad certification page" and "Page is not available" still aren't localized in the target language Device: Buri v1.2 Aurora COM RIL BuildID: 20131021004006 Gaia: 1fd315337d8ae891c3024e4c682c4c50797ea40e Gecko: d585fe28cd55 Version: 26.0a2 Firmware Version: US_20130930 RIL Information: 01.02.00.019.082
status-b2g18: --- → affected
status-b2g-v1.2: --- → affected
Hi, i would like to know that if multi-languages are supported in gecko? I am using V1.1HD,and it seems that only english is supported in gecko. And i could not figure out that when change system language,how it affects gecko language?
5 years ago
Duplicate of this bug: 931551
Not sure what to really do with this bug, moving it off my personal radar, though. It kinda seems to me that this is WONTFIX unless we get poked to actually fix it?
Assignee: l10n → nobody
Summary: gecko strings in firefox os not available in all 1.1 languages → gecko strings in firefox os not available in all languages
status-b2g-v1.4: --- → affected
Whiteboard: LocRun1.2, LocRun1.3 → LocRun1.2, LocRun1.3, LocRun1.4
status-b2g-v2.0: --- → affected
Whiteboard: LocRun1.2, LocRun1.3, LocRun1.4 → LocRun1.2, LocRun1.3, LocRun1.4, LocRun2.0
Whiteboard: LocRun1.2, LocRun1.3, LocRun1.4, LocRun2.0 → LocRun1.2, LocRun1.3, LocRun1.4, LocRun2.0, LocRun2.2
status-b2g-v2.1: --- → affected
status-b2g-v2.2: --- → affected
status-b2g-master: --- → affected
Whiteboard: LocRun1.2, LocRun1.3, LocRun1.4, LocRun2.0, LocRun2.2 → LocRun1.2, LocRun1.3, LocRun1.4, LocRun2.0, LocRun2.2, MGSEI-l10n-1F-Arabic
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [QAnalyst-Triage+][lead-review+][MGSEI-l10n-1F-Arabic]
Whiteboard: LocRun1.2, LocRun1.3, LocRun1.4, LocRun2.0, LocRun2.2, MGSEI-l10n-1F-Arabic → LocRun1.2, LocRun1.3, LocRun1.4, LocRun2.0, LocRun2.2,
[Blocking Requested - why for this release]: Seems like this bug has been around forever. I think we should get this on our radar for future releases and get a fix because current behavior is definitely not optimal. Nominating
blocking-b2g: - → 3.0?
I'd much rather remove the need to have this, aka, have bug 1067987 get traction.
D'oh! Forgot we were going down that road. Taking out nom'. How should we close this bug?
blocking-b2g: 3.0? → ---
Bug 1067987 is the way we'll try and push things forward. Closing this one as WONTFIX
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.