"Version Notes" for second listed version cannot be added during submission if the locale is changed

[ValentinaPC]

Steps to reproduce:

1. Submit a listed add-on https://addons.mozilla.org/en-US/developers/addon/submit/distribution
2. Add a second listed version for the submitted add-on using another locale
3. Observe "Release Notes" text field (from second step of version submission)

Expected results:
The text-field exist and notes about the version can be added.

Actual results:
The text-field doesn't exist. Version Notes cannot be added at that point, although info about adding version notes are displayed.

Notes/Issues:

• also, in English the section is named "Release Notes", but in other languages seems like the a translation of "Version Notes" is made - is this ok? Shouldn't we use the same name?
  Verified on FF51(Win 7). Issue is reproducing all around AMO-servers.
  Screenshot for this issue:
  

┆Issue is synchronized with this Jira Task

[diox]

From #4881 : note that editing the version notes does work. It's just broken at submission somehow (which is super weird as at this point, the Version has already been created, so it's kind of already an edition).

It might be due to the fact that Version does not have a default_locale field (which causes all sort of issues when the Addon.default_locale changes...) but maybe not.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. If you think this bug should stay open, please comment on the issue with further details. Thank you for your contributions.

[eight04]

Can still reproduce.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. If you think this bug should stay open, please comment on the issue with further details. Thank you for your contributions.

[netquik]

More than 5 years to fix this bug seems excessive to me. I just want to point out that for many if not most add-ons a reading of the updated description and release notes is critical. Although many add-ons can implement an internal changelog I believe this issue should be updated including that also the description of the add-ons itself is never updated.

In the issue that I had opened, now closed ,it is possible to see it. #1412

I just point out that this is not an exact duplicate but it adds other elements to this issue beyond the current parallel update issues.

Regardless of the inability to add release notes during the submission process, I believe that add-ons info should always take the updated data directly from the fields that can be edited in the developer's control panel. Otherwise it is much better to completely eliminate the tabs we are talking about and leave the burden to the user to go and check the description and news directly in the add-on. Leaving old data visible is always bad.

Now i don't know if the issue only occurs with locales other than en-US, if it is the case maybe forcing en-US on developer control panel should be a quick fix. I will switch my locale for next submission and will follow up.

[diox]

(side note: the update issue has been fixed in #8787)

This is entirely locale related. In your case, your add-on has some en-US and it translations for some fields and in some cases the it translation is even an empty string. Your browser is configured in it, and I guess the up to date description is the en-US one.

You can fix the translations in AMO: there is a Localize for: menu in the top right corner of the developer hub pages that have translated fields. Use that to look at the translations and fix or delete them. You can also use our API to look which fields need to be fixed.

In the future, staying on en-US when you're on AMO devhub would work around the issue.

Finally, yes, this bug is old now, but it's tied to some even older architecture decisions that are tough to change now, making it difficult to fix. Ultimately, it comes down to priority: there are more important and easier bugs for us to fix with the resources we have, so while it's still on our radar and we want to fix it, we can't promise anything.

[netquik]

@diox That is a great post. First of all thank you. Now I think I understand the problem and I will try to help solve it as soon as possible. For me a lot of things are not clear here, I mean it doesn't make much sense to have all the locales if then if a translated string is missing things don't work. Usually in these cases one should move in the opposite direction.

That is, everything must work in at least one language. However thanks again. As soon as I can I will try to understand if I can contribute to solving the problem at least in my local. I can definitely translate any English string into Italian. tomorrow I will see better how to be useful for this goal.

It makes me smile that my add-on is in any case written and intended for the international English-speaking market and the problems I have are in publishing English text. Like a paradox. Count on me if you (all community) need translations for the it-IT locale. Again thanks.

[diox]

It doesn't make much sense to have all the locales if then if a translated string is missing things don't work.

There is a fallback on the add-on default locale (en-US in your case) or the default locale for the site (also en-US). So displaying your add-on detail page in say, Spanish, would show the en-US translation correctly.

There are unfortunately 2 issues with that system:

• Developers don't necessarily realize what locale they are editing - by default it picks the one used on the site at the time, which can cause the issues you've experienced with your description not being up to date because you accidentally ended up with a version of it considered to be Italian. This is mostly an UX issue.
• The problem described above in which translated fields not on the main model don't work correctly and don't obey the add-on default locale fallback (not in your case though, because it's en-US) and, more importantly, aren't displayed properly (or at all!) in devhub for the developers when creating a new version. This is partly caused by the architecture decisions I alluded to earlier and how locales are stored in the database.

[netquik]

yes i can understand. but in any case as above said to me it make no sense. (just saying). I put hands on projects that have to be "located" but it has to be a plus not causing issues on behavior of internal functions. That is my opinion. Anyway i will try to help in in my little because i think it is a serious issue. Also note that as we are developers we should "at least" can understand en-US strings. We are not speaking of end users that then have to deal we developer market choice. I think that this issue hits developers first.. then all their users. Just that. For my case first option it can't be the case because i never use an italian word in any field, submission, manifest or such. FOr what i can understand without having digged on this problem, the issue is in the AMO locale UI.. then things go wrong in chain. But that is the reason why i was pointing on add-on description (apart from version notes textarea missing) ... The description of my add-on was never updated since first submission and it is written in english (or anyway not in italian). I have the impression that there is a problem that goes beyond the local issue. But i can't verify from here if any add-on was never updated (user side) from

[netquik]

ah also now i see my name instead of add-on name.. weird

that is after changing locale... my add-on has my name cool! 👯‍♂️

locales are just a mess...

[netquik]

Now some updates. I fixed my issue with description removing IT locale and editing default EN. As you can see above default EN had my name as the name of extension (don't know how that happened). After saving changes to description I checked on listing site and removed/added extension again. Now it took updated description. By the way version notes tabs is now missing at all. I tried to understand why, going to manage specific version. Set to EN it is as expected, changing to IT version notes are blank. Trying to editing IT locale result in nothing (it returns to EN and IT disappears from Localize for menu). After reloading from hub page it start again as described above. I will test for submission when possible to see if version notes comes up and i think that i will never touch locale again sticking on EN.

[eight04]

Uploaded a new version of Image Picka and can still reproduce this issue.

[KevinMind]

Old Jira Ticket: https://mozilla-hub.atlassian.net/browse/ADDSRV-147