Closed Bug 609670 Opened 14 years ago Closed 14 years ago

Error states for crazy new L10n UI

Categories

(addons.mozilla.org Graveyard :: Developer Pages, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED
5.12.3

People

(Reporter: clouserw, Unassigned)

References

Details

We have an awesome new L10n UI, but have questions on how to display errors in it. For example, if I add 3 new locales but some of the fields (on hidden elements) have errors, how do we display that?
chowse: We should chat so I can show you how I implemented your l10n mocks, so this solution fits well within that solution.
Blocks: 510046
Per discussion with Potch: Users should not be able to edit the add-on listing for more than one locale at a time. If the user switches locales while editing the listing, either: 1.) Their work should be saved immediately and the page reopened on the same form in the selected locale. If an error occurs during save, the appropriate errors should be displayed, and change of locale aborted. or 2.) The user should be prompted that changing locales will cause any unsaved changes to be lost. There user should then be provided the option to continue changing locales, or to cancel (or, if possible, to save and continue). If they chose to continue, their changes will be lost and the page will be reopened in the new locale. If they chose cancel, the change of locale is aborted. This ensures that only one locale is visible at any time, and therefore errors can be displayed in the same fashion as any other form on AMO. This also fits with the typical workflow of localization, which is done for a single language at a time across all fields. The only use cases this would hinder is if 1.) a user wanted to localize an add-on to many languages at once, or 2.) the user wanted to add or update a new field and had already localized the add-on to multiple languages. The former is only marginally inconvenience by this change (they simply need to hit save between locale switches). The latter, while a genuine nuisance, is an uncommon activity, is already inconvenience by having to return to the top of the page to switch locales, and may be moderated by the fact that localizations are often done my multiple people. In addition to the above change, switching locales should update the values of all static (non-editing) fields on the page to the appropriate locale, not en-US. There should be appropriate fallbacks where a localized value is not present. See the workflow below: http://people.mozilla.com/~chowse/drop/amo/devtools/v3/interaction/localization.png
Assignee: chowse → nobody
Thanks. I don't think use case #2 is mitigated by multiple people localizing since I don't know any authors that allow add-on edit permissions to people like that. But, let's give it a run. -> FIXED, as this is a design bug
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.