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? > > 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? -stas _______________________________________________ tools-l10n mailing list [email protected] https://lists.mozilla.org/listinfo/tools-l10n
