addons
addons copied to clipboard
mozilla
Declare language for user localized text
Describe the problem and steps to reproduce it:
- Browse the site in your default locale (such as French)
- Go an add-on detail page where the default locale of the description is something other than French (say, English)
What happened?
The section of the text in English does not have a lang attribute which means it will be interpreted as French (or whatever locale is in the URL).
What did you expect to happen?
It should have a lang attribute specifying the locale.
Anything else we should know?
- This is important for screen readers.
- The old site did it.
- We should probably also include the
dirattribute for right-to-left languages but I don't know what the practical usage of that is. - This should apply to all user localized data, such as reviews, version release notes, etc.
┆Issue is synchronized with this Jira Task
I mentioned this case to @eviljeff and he pointed out that if you specify lang in an API request you'll get only the locale you asked for. This however will fall back to other locales e.g. if you request lang=fr some descriptions will be in french but others will be in English but there's no data to be able to know that a given description is not the locale you requested.
To fix this we will need a fairly extensive breaking change in the API to annotate all localized content with the locale of the actual data returned to support this case.
For reference http://addons-server.readthedocs.io/en/latest/topics/api/overview.html#api-overview-translations is what we do at the moment.
We could change the API to always return a dict (with only the requested locale, or the default locale otherwise). But that would be a breaking change as mentioned (I don't know how reliant frontend is on the existing behavior). Or add another param that would return the dict, or some other structure that indicates the locale of each property.
@diox and @EnTeQuAk to look and ponder|despair.
We could change the API to always return a dict (with only the requested locale, or the default locale otherwise)
That would be my preference, because more query parameters are awful, but... backwards-compatibility breakage :( Still, the frontend could be modified in advance to cope with this change maybe? The APIs are marked as experimental in the docs precisely to allow us to do things like that, we don't guarantee their stability to the outside world.
Okay, so essentially I think we're agreed on always returning a dict for localised values. As its a breaking change frontend will need to do the work beforehand to handle it, or at least have the patch ready to merge. I don't think the API change is massive so shouldn't be much work on the addons-server side (though there will be many, many, test changes)
fwiw, this isn't blocked on API changes (and hasn't been for a few years) - the API response always indicates the locale of any localised field now.
@GregSherman
Should name also have the lang attribute?
There's a lang attribute for summary, description, developer comments and e-mail:
I'll cc @eviljeff in case Greg won't see the results.
