UI hints for translation status on translatable fields

[jeremydw]

Description

For fields and pages that are localized, content editors need a UI affordance to know whether a field has translation strings associated with it. Without a UI affordance, content editors must check the preview in multiple locales to know whether a field is translated. Additionally, they may unknowingly make a content change which will result in the loss of a translation.

To fix this, we should bubble up information about the translation status of a field.

Here is an example mock, although it's just for brainstorming.

The idea is:

1. When a field is translatable, show the translations icon
2. For fields with translations, show the green checkmark to signal that the field is fully translated
3. For fields without translations, show the warning icon

We should also consider the situation where one locale has translations for a field but not all (this isn't mocked).

Finally, we should be mindful of cluttering the CMS UI. I do think that translation status is worthy of adding a UI hint for, but we should be mindful about the visual design of the hint.

Clicking the icon could invoke the Localization dialog with the relevant field focused.

[stevenle]

FYI I'm not a big fan of showing actionable status symbols since some fields may never be translated for whatever reason and so it'd be like having the "check engine" light always on. I can do something like "show it in green" if it has translations, or some other color otherwise, which is less intrusive.

This also may be a costly feature (in terms of RPCs) since it requires a check for translations for every field, which means it fetches a db entry for every field in the system regardless of whether the user cares about translations or not. I'd rather just show the translation icon and when clicked it shows the user the translations for that field (without status) which would have less RPCs and is more scalable.

[jeremydw]

We could also consider showing the status only whenever a user focuses or edits a field. Although this signals less information it would still help guard against the primary problematic scenario which is when a user edits a field without knowing it breaks the translation link. That would save on RPCs and not clutter the default UI while still guarding against the primary use case for the feature.

[stevenle]

I also just realized that as soon as user starts typing anything into the field, the source string would change and the translation status would be "broken" and require another check. I don't think it would be scalable to show a translations check by default, so options are:

1) show the translations icon only, when clicked a modal pop up appears with the string(s) used and the translations available for that string.

2) we can have a menu option that says "enable translations mode" which takes a snapshot of all the strings currently used and makes a batch request to see if translations exist for each string. we can show the extra ui options you've outlined in this "mode" (e.g. "enable translations mode" or something). (and once a user starts typing into any field, it would naturally break the status of that translations icon)

[jeremydw]

Adding the translations icon I think is a good first step; when the user clicks the icon it can bring up the Localization modal with the string field focused or just a single string like you're saying.

Re: "enable translations mode" menu, I'm wondering if we should just incorporate the translations check into the "publishing checks" feature that we've been thinking about. One of the checks that could run when a page is being published is whether we have translations for all the fields, so the information on "whether a translation is missing" could be conveyed there instead. (And a missing translation would probably be a "warn" instead of a "fail".)