search

l20n / spec

Specification and design documents for L20n
http://l20n.github.com/spec/
10 stars 6 forks source link

Have sections work more like a PO context #11

Closed GlenDC closed 7 years ago

GlenDC commented 7 years ago

Currently sections seem to be only used by toolchains. I think there is however a missed opportunity in this. In PO files they have the concept of a "context", which allows multiple entries with the same id (identifier in L20n, msgid in PO), as long as they have a different context (I'm assuming that an entry is in a default context when none is specified).

I guess you could also go the CSS route where such ambiguity is resolved by having the namespace as part of the name. However, as we already provide a section element, I don't see why we wouldn't also have such entries linked to a section for actual usage in libraries such as L20n.js, and whatever other languages are available.

Reference: https://www.gnu.org/software/gettext/manual/html_node/PO-Files.html (see: msgctxt)

GlenDC commented 7 years ago

@stasm I've been trying to follow the mailing list of L20n. However I don't really receive my digests often, so I might have missed some discussion about this issue. Has it ever been considered to give context also a meaning in terms of (optional) scoping, when used to reference entities within FTL files. This would help with name conflicts and would avoid people having to name their entities namespace_entity, as people seem to do with CSS.

In case this is an item that is interesting and worthy a discussion, should I re-open this issue in https://github.com/projectfluent/syntax?

stasm commented 7 years ago

Are naming conflicts a common problem? I'd like to think that an easy way of solving them is using short unambiguous prefixes in the identifier: foo-, bar- etc. In gettext, msgctxt is required because there are no identifiers and the translation value serves that purpose.

In https://github.com/projectfluent/syntax/issues/10 we're discussing making sections even simpler than they are right now. That would go against your proposal here, and I'd like to hear your thoughts.

In general, we found that sections-as-namespaces were confusing. In particular, it wasn't clear how a message called foo placed inside of a sec section should be requested from the outside code. We decided that requiring to repeat the section name in every call (e.g. sec/foo, sec/bar etc) would have been too verbose.

GlenDC commented 7 years ago

I guess that does make sense. I suppose that means that for application libraries (anything that is not tooling), those headers could be ignored? Thanks for clarifying, and I'm all in favor of that proposal. And I do think you're right, it would indeed become a bit verbose. Closing this in favor of your proposal.

stasm commented 7 years ago

I suppose that means that for application libraries (anything that is not tooling), those headers could be ignored?

That's the intent, yes.