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)
addons.mozilla.org Graveyard
Developer Pages
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?
Comment 1•14 years ago
|
||
chowse: We should chat so I can show you how I implemented your l10n mocks, so this solution fits well within that solution.
Comment 2•14 years ago
|
||
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
Reporter | ||
Comment 3•14 years ago
|
||
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
Assignee | ||
Updated•9 years ago
|
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•