885470 - [L10n] Marketplace Account Settings: country name in English

Status: RESOLVED FIXED

(Marketplace Graveyard :: General, defect)

Description

[Inma Barrios]

Attachment: Marketplace Account Settings Web Page

Marketplace website set to Spanish

Screenshot of Marketplace Account Settings web page

Description:
A user with their device/computer language set to Spanish will see Marketplace Account Settings web page displaying some English and truncated strings.

Repro Steps:

1) Click on https://marketplace.firefox.com/settings
2) Make sure your language is set to Spanish
3) Observe the appearance of the page:
-Truncated string: "Configuración de l..." instead of "Configuración de la cuenta";
-License text at the footer in English;
-Region in English. (I also clicked on the drop-down menu and none of the countries or regions is translated, and there's no l10n file for them either).


Actual:
Marketplace Account Settings web page both English and truncated strings.

Expected:
Account settings displays in Spanish and no truncated text.

Comment 1

[Peiying Mo [:CocoMo]]

There are several issues raised here:
-country list in English - can we leverage existing strings (US and localized version) and move it to github?
-truncated strings - is it possible to indicate the maximum of the string length for the space?  Is it possible to allow the space expand vertically?  This will become a serious issue when we test german
-licence verbiage on the bottom: hard coded strings.  

Thank you,
Peiying

Comment 2

[Delphine Lebédel]

Hi Inma. Thanks for reporting this.

Please next time give us more information on the build and phone you are using (build version, gaia/gecko version, build id)

I've taken myself out of the Assignee section as I am not the one who can fix this.

I've just checked this on Leo phone, v1.1 Moz RIL build, 
Gaia   c507ff65b51194383da65f8927164f078a3e1f79
BuildID 20130620070209
Version 18.0

I don't have the same issue as you. I suspect your screenshot comes from a computer and not a FirefoxOS device? If it is from a phone, are you sure you've updated to the most recent build?
thanks

Comment 3

[Inma Barrios]

Attachment: FirefoxOS Marketplace Account Settings

Hi Delphine,

Sorry about the confusion. Yes, you're right - there are two different issues here:

#Firefox for desktop (that's the screenshot I attached first):
*Country list in English,
*Truncated string and
*License text in English.

#Firefox OS (please find the new screenshot attached):
*Country list in English.

I have a Keon B2G v1.0.1.0 prerelease, platform version 18.0. That's the most recent build.

Thanks for your help :)

Comment 4

[Mathieu Pillard [:mat]]

So there are 3 different issues here: 
- Country list untranslated
- Truncated header in spanish
- Website licence text in the footer untranslated

Can you open up different bugs for each issue ? Thanks.

Comment 5

[Peiying Mo [:CocoMo]]

I will create separate bugs then.   I will leave this one for Country list issue.

Please leverage existing translation to this string so localizers don't have to translate it again if possible.

Comment 6

[Wil Clouser [:clouserw]]

(In reply to Peiying Mo from comment #5)
> I will create separate bugs then.   I will leave this one for Country list
> issue.
> 
> Please leverage existing translation to this string so localizers don't have
> to translate it again if possible.

Depending on the tools the localizers are using they may get this for free already.  Many tools support this (I think called a dictionary?).

Comment 7

[Peiying Mo [:CocoMo]]

Actually this one is for both all the currently available country options.

Wil,
I am wondering if this is something dev can do, s we don't count on localizers to complete the tasks.  In other words, can we make it so it doesn't even show up in the untransalted string stats you put out weekly?

Comment 8

[Christopher Van Wiemeersch [:cvan]]

Basta, http://dpaste.com/1270058/ <-- these are legitimate calls to `gettext`, but `make langpacks` doesn't seem to extract these strings. Ideas?

Comment 9

[Matt Basta [:basta]]

Not sure. Try adding some debugging here:

https://github.com/mozilla/fireplace/blob/master/scripts/compile.js#L82

Comment 10

[Inma Barrios]

(In reply to Wil Clouser [:clouserw] from comment #6)
> (In reply to Peiying Mo from comment #5)

> > Please leverage existing translation to this string so localizers don't have
> > to translate it again if possible.
> 
> Depending on the tools the localizers are using they may get this for free
> already.  Many tools support this (I think called a dictionary?).

Hi,

Well I don't think it's a question of using a dictionary or not, but of using l10n resources and assets more efficiently, including helping localizers save their precious time.

I totally agree with Pei on the proposal of leveraging existing translations whenever possible.

Thanks for trying to make things easier, Pei!

Comment 11

[Wil Clouser [:clouserw]]

(In reply to Peiying Mo from comment #7)
> Actually this one is for both all the currently available country options.
> 
> Wil,
> I am wondering if this is something dev can do, s we don't count on
> localizers to complete the tasks.  In other words, can we make it so it
> doesn't even show up in the untransalted string stats you put out weekly?

We don't have a way of doing that at this time.  I think using a dictionary is the fastest solution.

Comment 12

[Peiying Mo [:CocoMo]]

Hi Wil,

This is what Pascal shared with me regarding country list: http://viewvc.svn.mozilla.org/vc/libs/product-details/regions/ - is this what you called "dictionary"?  Is there a way to pull data from here as it is already done?

If not, given the time we have left before final sign off, do what's quick.  I am going to push to get common data info (country name, language, city name, etc) leveraged in the future.  

Thank you,
Peiying

Comment 13

[Wil Clouser [:clouserw]]

That's the right idea, but it would be up to the tools the localizers use to translate .po files if they support dictionaries and the formats.  It's not a standard thing because we don't require the use of specific tools.

Comment 14

[Christopher Van Wiemeersch [:cvan]]

https://github.com/mozilla/fireplace/commit/5186bfd

Basta, it's all you =)

Comment 15

[Matt Basta [:basta]]

cvan: That's all that was needed. `make langpacks` doesn't run the extraction. You should have been running `make l10n`. The `langpacks` target only compiles the PO files into JS.

The strings should go out to the localizers the next time Wil runs the string extraction.

Comment 16

[Axel Hecht [:Pike]]

Why do we need to create a new scheme of localizing countries here?

We have json data readily available at http://viewvc.svn.mozilla.org/vc/libs/product-details/json/regions/ in case you're concerned about the .properties.

AFAIK, this is the data we're using elsewhere in the project to get localized country names, and how we're starting to key off of English country names, and on a weird subset.

Comment 17

[Matt Basta [:basta]]

(In reply to Axel Hecht [:Pike] from comment #16)
> Why do we need to create a new scheme of localizing countries here?
> 
> We have json data readily available at
> http://viewvc.svn.mozilla.org/vc/libs/product-details/json/regions/ in case
> you're concerned about the .properties.
> 
> AFAIK, this is the data we're using elsewhere in the project to get
> localized country names, and how we're starting to key off of English
> country names, and on a weird subset.

Sorry this is a hassle. There are a couple reasons we're doing this:

- We've got a very complicated L10n pipeline that we're still getting established. Unlike with server-side projects, we're still getting our sea legs on the client-side and have to build any new tools from scratch. We presently don't support JSON locale files (only PO), or multiple strings files per locale.
- These aren't necessarily country names, they're region names. For now our regions countries. Going forward though, they may include larger or smaller cultural boundaries, as well as individual states or legal "zones". I wouldn't be surprised if the US and Canada were considered a single region, for instance.

Again, sorry for the frustration. For now there are only a small handful of regions to be localized. As more are added, I'd encourage you to file a new bug so we can brainstorm about integrating with existing infrastructure (like you've linked to) to help ease the burden on the L10n team.