609670 - Error states for crazy new L10n UI

Status: RESOLVED FIXED

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

Description

[Wil Clouser [:clouserw]]

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

[Potch [:potch]]

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

[Chris Howse [:chowse]]

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

Comment 3

[Wil Clouser [:clouserw]]

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