On 10/22/15 6:06 PM, Staś Małolepszy wrote:
It looks like the main concern here is the idea of sparse localizations.
My overall vote goes towards maintaining consistency of entities, but I'd
like to suggest to split this topic into three categories:
1. 'standalone' attributes, like title, which provide a separate piece of
content that's somehow related to the value of the element,
2. 'support' attributes, like accesskey, which are strictly related to the
value of the element, and
3. 'dominant' attributes, like ariaLabel or placeholder, where the
attribute is really _the_ value of the element.
I'll start in reversed order:
3. a missing dominant attribute means that the whole entity is no good;
it's unlikely that the entity even has a value, so the consistency rule
gives good results here.
I also think that in this context, this scenario doesn't pose any
challenge? We'll be falling back to whatever is in the fallback chain,
independent of what we discuss here?
2. a missing support attribute may result in weird UI like we see it in
Firefox when the accesskey doesn't match any of the letters of the string;
for sparse localizations, erring on the side of consistency/responsibility
seems to me like the right choice: if you change the string, you also need
to copy and change the attribute. A missing support attribute is thus an
error, too.
I don't think I agree.
As much as I agree on the general attitude that we want complete
localizations, we just don't have them.
Maybe my thinking can be reworded better:
Is there a element/attribute(s) combination, where you can't test one
without the other, even for a local build, or a runtime fallback combo?
Is that case common enough to dominate our thinking?
That to me is hard to say "yes" to.
(In particular for accesskeys we could do semi-smart things on buildtime if
we knew the next significant language the sparse localization is based on,
like falling back on the next language and errorring out only if the letter
is not present in the translation string.)
1. for standalone attributes, I think it would make the most sense to
consider per-attribute fallback. However, for conistsency with the
behavior in #2 and #3, I'd suggest treating them as errors, too. I think
this follows the principle of least surprise.
As you're talking about consistency here, I think the point in 2. needs
to be figured out first.
Axel
* * *
Coming back to compare-locales, I think we should do the following:
- error on obsolete value/attributes,
- error on missing value/attributes,
- remove the is-resolvable check for hashes,
- parser-error on hashes without a default value.
Specifically, obsolete values/attributes should be errors not warnings
because they can leak into the DOM where they shouldn't and can break the
UI.
-stas
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n
