Closed
Bug 1223887
Opened 10 years ago
Closed 9 years ago
verify all product locales are covered by Input
Categories
(Input :: General, defect, P1)
Input
General
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: willkg, Unassigned)
References
Details
Firefox supports a set of locales. It has in-product links to Input which include those locales in the url. For locales that Firefox supports that Input does not, Input kicks up an HTTP 404. For example:
https://input.mozilla.org/foo/feedback/
This is true for all other products, too: Firefox for Android, Firefox for iOS, Firefox OS, Firefox dev edition and the product that will remain nameless for a while longer.
This bug covers finding a source for the master list of locales that our product supports. Once we have that source, we can get the current list. Once we have that, we can see which ones fail on Input. Once we have that, we can fix things so everything works. We probably want to do that with redirects or adding those locales to svn or something like that.
This is probably a big deal at least until we find out whether users are seeing HTTP 404 errors and the impact of that, so making this a P1 for now.
| Reporter | ||
Comment 2•10 years ago
|
||
I spent some time looking at inputweb1 404 errors and other than the example I have in the description, I see no other issues. I used this grep string:
grep " 404 " access_2015-11* | grep " /en-US/" | grep -v favicon | grep -v "apple-touch"
It's not exact, but it was good enough to reduce the hits to a set that was easy to skim through.
product-details includes a languages.json file which maps locale codes -> (english name, native name). I'm pretty sure we can use that as a "this is everything" list.
Input builds it's PROD_LANGUAGES in settings.py manually. It used to look at the locale/ directory, but I'm pretty sure I changed that at some point. I forget why exactly.
I think fixing this involves the following:
1. change settings so PROD_LANGUAGES is generated by looking at locale/
2. writing a new django management command that goes through the list of locales in languages.json and generates the appropriate directories in locale/
3. writing up the process of syncing languages to the docs
Then the process goes like this:
1. run the new command
2. go through all the directories in locale/ that aren't in version control and add them
3. run extract and merge
4. push all that to the locale/ version control system
5. do a deploy
I very much doubt we change languages often. We could throw together a test that runs locally if locale/ exists and checks things. That'd probably be sufficient, short and easy to do. We could hook it up to travis, too.
Anyhow, given that I don't see any evidence that this problem is actually happening, I'm going to push it off and unassign myself.
Assignee: willkg → nobody
Status: ASSIGNED → NEW
I got a list from *somewhere*
https://github.com/mozilla/self-repair-server/blob/master/scripts/all-locales.js#L34
var LANGS = [
'ach', 'af', 'ak', 'an', 'ar', 'as', 'ast', 'az', 'be', 'bg',
'bn-BD', 'bn-IN', 'br', 'bs', 'ca', 'cs', 'csb', 'cy', 'da',
'de', 'dsb', 'el', 'en-GB', 'en-US', 'en-ZA', 'eo', 'es-AR', 'es-CL',
'es-ES', 'es-MX', 'et', 'eu', 'fa', 'ff', 'fi', 'fr', 'fy-NL',
'ga-IE', 'gd', 'gl', 'gu-IN', 'he', 'hi-IN', 'hr', 'hu', 'hy-AM',
'hsb', 'id', 'is', 'it', 'ja', 'ja-JP-mac', 'ka', 'kk', 'km', 'kn',
'ko', 'ku', 'lg', 'lij', 'lt', 'lv', 'mai', 'mk', 'ml', 'mn',
'mr', 'ms', 'my', 'nb-NO', 'nl', 'nn-NO', 'nso', 'oc', 'or', 'pa-IN',
'pl', 'pt-BR', 'pt-PT', 'rm', 'ro', 'ru', 'sah', 'si', 'sk', 'sl',
'son', 'sq', 'sr', 'sv-SE', 'sw', 'ta', 'ta-LK', 'te', 'th', 'tr',
'uk', 'ur', 'vi', 'wo', 'xh', 'zh-CN', 'zh-TW', 'zu',
];
// RTL languages.
var RTL_LANGS = ['ar', 'fa', 'he', 'ur'];
| Reporter | ||
Comment 4•10 years ago
|
||
That's helpful. I need a definitive source that I can sync against over time, though. I'm pretty sure product-details covers that need. It'd be interesting if your list matched what was in product-details. I'll check that when I get a chance.
Comment 5•9 years ago
|
||
This might help https://product-details.mozilla.org/regions/en-US.json
Comment 6•9 years ago
|
||
The Input service has been decommissioned (see bug 1315316) and has been replaced by a redirect to an external vendor (SurveyGizmo). I'm bulk WONTFIXing Input bugs that do not appear to be relevant anymore.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•