addons
addons copied to clipboard
mozilla
Collection name and description display different values specific to the locale used when the fields were edited
Refiled from https://github.com/mozilla/addons/issues/5592
STR:
- Log in to AMO -dev
- Go to My Collections and select one of your collections to view its details page
- Switch to a different locale
- Edit the collection name and description
- Switch back to the previous locale
Actual result: The updated collection name and description are not displayed
Expected result: Updated collection name and description should be displayed regardless of the locale used when the fields are edited
Notes:
- a localization issue (#https://github.com/mozilla/addons/issues/11651) was was also reported for the legacy edit collection page, currently in use
- reproduced on AMO -dev with FF60, WIn10x64
┆Issue is synchronized with this Jira Task
Comment from @diox
In devhub we display a widget allowing you to see / edit localized fields in all languages. The API was designed for this as well, returning all translations if you don't pass a lang parameter. So the frontend can implement something like this. In any case, it's a frontend bug. The bug is really that the frontend should let you know which locale you're editing and possibly let you see/edit other locales at the same time.
This is the same localizedString issue that we've come across for reviews, as well as something else I cannot recall. I'm not sure that these localizations are something that we want to support on the front end. The implementation allows for a user to have different versions of a collection name and description for different locales, but I don't think that's actually something we intend to support. I think it's just a result of the implementation.
We should discuss whether this is something we want to support, and if not we should consider making these simple strings rather than localizedStrings because the latter only seems to cause headaches.
@jvillalobos what do you think?
We need to go back to addons-server then and modify the API to make these fields proper CharFields (which will require database migrations)
I do think that makes the most sense, and I also realize it isn't an entirely trivial task. I think we should take that approach with any localizedStrings that we don't intend to actually be localizable, as we seem to keep having issues with them.
@diox Should we create an issue on addons-server for this?
I opened https://github.com/mozilla/addons/issues/5716 to cover this on the server. We can keep this issue open as something to verify once that change has been made.
