Closed Bug 816151 Opened 7 years ago Closed 7 years ago

[browser] Upon first launch the URL bar changes from Capital letters to lower case letters.

Categories

(Firefox OS Graveyard :: Gaia::Browser, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: nhirata, Unassigned)

Details

(Keywords: polish)

Attachments

(1 file)

## Environment :
Unagi phone, build 2012/11/27
  
## Repro :
1. launch browser for the first time

## Expected :
1. URL bar's capitalization does not change

## Actual :
1. it goes from upper to lower case

## Note :
http://www.youtube.com/watch?v=XWIg7daq_Lg&feature=youtube_gdata_player
This is the same issue as bug 815852. The problem is that you're seeing the hardcoded string in the HTML first. If you were using a different locale, this string would even change language.
ew.  ya. I saw that...  

I know this sounds petty... (because... well it is) Are we suppose to have the English capitalized?  

https://github.com/mozilla-b2g/gaia/commit/0e37231ab5d1b5cbe0e23146b94382d12cb97f44#L1R10
Stas and Matej did an in-depth review of all the en-US strings recently, so whatever is in the .properties file should be correct.

The bug here is really that we're showing a string before getting the 'localized' event.
OK, this particular bug was caused by the string being changed in the .properties file and not the HTMl file but as Margaret points out there's a wider problem of momentarily seeing the wrong language if you're using a language other than English.

I can easily fix the capitalisation problem by changing the string in HTML but to solve the wider problem there are several possible approaches.

1) Wait for the event to get fired to indicate localisation is complete before displaying the UI. This will degrade perceived app startup time.
2) I can strip out all the default strings from the HTML file (which are only there in keeping with convention across Gaia), but there's a danger that might cause visual reflows as the strings get added.
3) Fabien thinks we need a different long term solution to this, possibly generating a version of all HTML files for each locale at build time.

I'm not sure which approach to take because whatever we do we should probably be consistent across Gaia.
(In reply to Ben Francis [:benfrancis] from comment #4)

> 2) I can strip out all the default strings from the HTML file (which are
> only there in keeping with convention across Gaia), but there's a danger
> that might cause visual reflows as the strings get added.

This is also true if the localized string is a different size than the en-US string that's in the HTML, so that doesn't seem like a good reason for keeping the en-US strings in the HTML (see bug 812993 for more discussion about removing strings).

> 3) Fabien thinks we need a different long term solution to this, possibly
> generating a version of all HTML files for each locale at build time.

Replacing the strings in the HTML definitely feels out of reach for v1. In bug 809600 we experimented with at least pre-loading the strings in a JS object so that getting to that 'localized' event would be faster, but that work got stalled and nothing has landed.

> I'm not sure which approach to take because whatever we do we should
> probably be consistent across Gaia.

I agree, I think there's a lack of clear best practices for l10n for gaia, so we should communicate this more broadly. I also think we really need people testing in non en-US locales, because developers using en-US are not noticing these types of bugs where strings are getting swapped after the UI is showing.
I'm cc'ing Bhuvana here because she's looking into bug 815852, and we should coordinate the solutions to these bugs.
NOTE: If blocking-basecamp+ is set, just land it for now.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
User impact if declined: 
Testing completed: 
Risk to taking this patch (and alternatives if risky):

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
User impact if declined: 
Testing completed (on m-c, etc.): 
Risk to taking this patch (and alternatives if risky): 
String or UUID changes made by this patch: 

It pains me to do this, but this patch removes all the default strings from the HTML. This will degrade perceived loading time for English speakers, but puts English on an even footing with other languages and prevents the visible translation glitch from happening!

I didn't make use of the localized event as I'm still not sure that's the right thing to do, at least this way we show *something*, but I'm not sure if that's better than waiting for everything to be ready before displaying anything.
Attachment #688826 - Flags: review?(dale)
Attachment #688826 - Flags: approval-gaia-master?(21)
Attachment #688826 - Flags: review?(dale)
fixed by https://bugzilla.mozilla.org/show_bug.cgi?id=815852
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Attachment mime type: text/plain → text/x-github-pull-request
You need to log in before you can comment on or make changes to this bug.