| 2012-10-11 08:57:44 |
David Planella |
bug |
|
|
added bug |
| 2012-10-11 08:57:54 |
David Planella |
visibility |
private |
public |
|
| 2012-10-11 08:58:06 |
David Planella |
bug task added |
|
ubuntu-translations |
|
| 2012-10-11 08:58:17 |
David Planella |
bug task added |
|
webapps-applications (Ubuntu) |
|
| 2012-10-11 08:58:29 |
David Planella |
ubuntu-translations: status |
New |
Triaged |
|
| 2012-10-11 08:58:33 |
David Planella |
ubuntu-translations: importance |
Undecided |
High |
|
| 2012-10-11 23:49:44 |
Launchpad Janitor |
branch linked |
|
lp:webapps-applications |
|
| 2012-10-11 23:50:04 |
Maxim Ermilov |
webapps-applications: status |
New |
Fix Committed |
|
| 2012-10-18 09:57:16 |
David Planella |
ubuntu-translations: status |
Triaged |
Fix Committed |
|
| 2012-10-23 14:17:27 |
Launchpad Janitor |
branch linked |
|
lp:~ken-vandine/webapps-applications/2.4.10 |
|
| 2012-10-24 06:52:08 |
Ken VanDine |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2012-10-27 06:22:09 |
Steve Langasek |
description |
Currently the code to detect the user's language preference to load the translations for webapps is the following (in common/utils.js):
var lang = unsafeWindow.navigator.language; //TODO: came up with a better approach
if (dict.hasOwnProperty(lang) && dict[lang].hasOwnProperty(strid)) {
return dict[lang][strid];
} else {
return strid;
}
'dict' is a variable containing a JSON string that is populated at build time with the contents of the translations in .po files in the source tree. It includes the locale code as read from the .po (or LINGUAS) files, which is a gettext-style locale code.
The problem is that the 'lang' variable as returned from the browser in some cases won't match the user's locale. This is mainly due to the fact that Firefox uses IETF-style language codes, whereas the system uses gettext-style language codes. That means for some languages there won't be a match, and thus translations won't be loaded. Here's an example for Simplified Chinese:
- Gettext locale code: zh_CN
- Firefox locale code: zh-cn
So there must be a translation gettext -> Firefox (and Chromium, if it returns locales in a different format) at build time, so that locale names from the system and from the browser can match and translations can be loaded.
Also notice that in some cases either the country code in the locale code might be present in the system locale but not in the browser, and viceversa, so it might be an idea to ignore the country code apart from some exceptions (e.g. zh_CN and zh_TW, pt_BR, etc., to name a few) |
[IMPACT]
Language detection code will not work for some languages
[TESTCASE]
1. LC_ALL=zn_CN.UTF8 firefox
2. open gmail
action's name in launcher should be localized
[Regression Potential]
none
Currently the code to detect the user's language preference to load the translations for webapps is the following (in common/utils.js):
var lang = unsafeWindow.navigator.language; //TODO: came up with a better approach
if (dict.hasOwnProperty(lang) && dict[lang].hasOwnProperty(strid)) {
return dict[lang][strid];
} else {
return strid;
}
'dict' is a variable containing a JSON string that is populated at build time with the contents of the translations in .po files in the source tree. It includes the locale code as read from the .po (or LINGUAS) files, which is a gettext-style locale code.
The problem is that the 'lang' variable as returned from the browser in some cases won't match the user's locale. This is mainly due to the fact that Firefox uses IETF-style language codes, whereas the system uses gettext-style language codes. That means for some languages there won't be a match, and thus translations won't be loaded. Here's an example for Simplified Chinese:
- Gettext locale code: zh_CN
- Firefox locale code: zh-cn
So there must be a translation gettext -> Firefox (and Chromium, if it returns locales in a different format) at build time, so that locale names from the system and from the browser can match and translations can be loaded.
Also notice that in some cases either the country code in the locale code might be present in the system locale but not in the browser, and viceversa, so it might be an idea to ignore the country code apart from some exceptions (e.g. zh_CN and zh_TW, pt_BR, etc., to name a few) |
|
| 2012-10-27 06:29:46 |
Steve Langasek |
nominated for series |
|
Ubuntu Quantal |
|
| 2012-10-27 06:29:46 |
Steve Langasek |
bug task added |
|
webapps-applications (Ubuntu Quantal) |
|
| 2012-11-04 01:59:07 |
Steve Langasek |
webapps-applications (Ubuntu Quantal): status |
New |
Fix Committed |
|
| 2012-11-04 01:59:12 |
Steve Langasek |
bug |
|
|
added subscriber SRU Verification |
| 2012-11-04 01:59:14 |
Steve Langasek |
tags |
|
verification-needed |
|
| 2012-11-04 12:23:32 |
David Planella |
description |
[IMPACT]
Language detection code will not work for some languages
[TESTCASE]
1. LC_ALL=zn_CN.UTF8 firefox
2. open gmail
action's name in launcher should be localized
[Regression Potential]
none
Currently the code to detect the user's language preference to load the translations for webapps is the following (in common/utils.js):
var lang = unsafeWindow.navigator.language; //TODO: came up with a better approach
if (dict.hasOwnProperty(lang) && dict[lang].hasOwnProperty(strid)) {
return dict[lang][strid];
} else {
return strid;
}
'dict' is a variable containing a JSON string that is populated at build time with the contents of the translations in .po files in the source tree. It includes the locale code as read from the .po (or LINGUAS) files, which is a gettext-style locale code.
The problem is that the 'lang' variable as returned from the browser in some cases won't match the user's locale. This is mainly due to the fact that Firefox uses IETF-style language codes, whereas the system uses gettext-style language codes. That means for some languages there won't be a match, and thus translations won't be loaded. Here's an example for Simplified Chinese:
- Gettext locale code: zh_CN
- Firefox locale code: zh-cn
So there must be a translation gettext -> Firefox (and Chromium, if it returns locales in a different format) at build time, so that locale names from the system and from the browser can match and translations can be loaded.
Also notice that in some cases either the country code in the locale code might be present in the system locale but not in the browser, and viceversa, so it might be an idea to ignore the country code apart from some exceptions (e.g. zh_CN and zh_TW, pt_BR, etc., to name a few) |
[IMPACT]
Language detection code will not work for some languages, impeding their translations from being loaded and thus displaying English prompts to non-English speakers who have an otherwise localized desktop.
[TESTCASE]
1. LC_ALL=zn_CN.UTF8 firefox
2. open gmail
action's name in launcher should be localized
[Regression Potential]
none
Currently the code to detect the user's language preference to load the translations for webapps is the following (in common/utils.js):
var lang = unsafeWindow.navigator.language; //TODO: came up with a better approach
if (dict.hasOwnProperty(lang) && dict[lang].hasOwnProperty(strid)) {
return dict[lang][strid];
} else {
return strid;
}
'dict' is a variable containing a JSON string that is populated at build time with the contents of the translations in .po files in the source tree. It includes the locale code as read from the .po (or LINGUAS) files, which is a gettext-style locale code.
The problem is that the 'lang' variable as returned from the browser in some cases won't match the user's locale. This is mainly due to the fact that Firefox uses IETF-style language codes, whereas the system uses gettext-style language codes. That means for some languages there won't be a match, and thus translations won't be loaded. Here's an example for Simplified Chinese:
- Gettext locale code: zh_CN
- Firefox locale code: zh-cn
So there must be a translation gettext -> Firefox (and Chromium, if it returns locales in a different format) at build time, so that locale names from the system and from the browser can match and translations can be loaded.
Also notice that in some cases either the country code in the locale code might be present in the system locale but not in the browser, and viceversa, so it might be an idea to ignore the country code apart from some exceptions (e.g. zh_CN and zh_TW, pt_BR, etc., to name a few) |
|
| 2012-11-05 08:07:39 |
Olivier Febwin |
tags |
verification-needed |
verification-done |
|
| 2012-11-09 20:42:13 |
Launchpad Janitor |
webapps-applications (Ubuntu): status |
New |
Fix Released |
|
| 2012-11-12 01:07:42 |
Colin Watson |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2012-11-12 01:08:12 |
Launchpad Janitor |
webapps-applications (Ubuntu Quantal): status |
Fix Committed |
Fix Released |
|
| 2012-11-12 23:52:39 |
Maxim Ermilov |
webapps-applications: status |
Fix Committed |
Fix Released |
|
| 2012-11-20 11:56:23 |
Adolfo Jayme Barrientos |
ubuntu-translations: status |
Fix Committed |
Fix Released |
|
| 2013-02-15 18:33:47 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/quantal-proposed/webapps-applications |
|
| 2013-05-03 16:01:06 |
Nobuto Murata |
bug |
|
|
added subscriber Nobuto MURATA |
| 2014-02-24 06:49:30 |
Adolfo Jayme Barrientos |
bug task deleted |
webapps-applications (Ubuntu Raring) |
|
|
