On 9/11/15 5:55 PM, Staś Małolepszy wrote:
On Thu, Sep 10, 2015 at 5:35 PM, Axel Hecht <[email protected]> wrote:

While hacking on a compare-locales impl for l20n, we came across
unresolved entities and attributes.

That is hashes without index and/or default values, used for either the
value or an attribute.

Is there a usecase for that?


One use-case is the one being currently discussed in the byteUnit thread.
In essence:  how to store arbitrary data which can be re-used in
translations?

Regardless of the outcome of that discussion, perhaps we should consider
banning hashes without default values.  This would definitely make for
safer translations and improve the quality of l20n code.

What do you think: should we make that a ParserError?

Might make sense.


My personal take is that that should be a compiler error.

Most prominently, I think that hash keys are language-internal, and as
such shouldn't be exposed to the outer world.


I agree on hash keys.  There are other parts of the public interface of an
entity, however: value and public attributes.  Is this also part of the
'resolvable' discussion?  I think it would make sense to report missing
values and public attributes as compare-locales errors because they violate
the social contract and can break the expectations of the consumer code.
In compare-locales.js we wanted to have a special state for this:
malformed.  What are your thoughts about this?

We're calling malformed an error/warning right now. Missing is an error, obsolete is a warning.

I'm not sure that's ultimately the right answer, in particular in the light of locales which want to re-use en-US accesskeys.

I'd like to make that easy.

Doesn't make l10n-merge easier, though :-)

I'm wondering, can we restrict ourselves in the model here to DOM nodes.

In which case an obsolete attribute might actually be an error in the sense that the l10n-merge code should remove it, while a missing attribute (or value) might be just a warning?

Axel
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n

Reply via email to