Thanks for sharing your thoughts, Axel! On Mon, Jul 20, 2015 at 11:19 PM, Axel Hecht <[email protected]> wrote:
> > * Operators require whitespace separation > This is basically that (- foo bar) and (-foo bar) are two different things. > > I think that's a fine conversation to have, and I see how enabling > operator chars inside IDs can be a pro. > The point about required whitespace is a good one. It's worth noting that our current syntax also requires whitespace in certain places, e.g. before an attribute's id. > * Operator-first notation > This one, sorry, is just awkward. No kid learns math this way. 1 + 3 is > elementary school, and I might go into details of how I suffer from people > not getting this right, but seriously, this is something we should build > on, and not break. > I'm not going to argue with that :) Would it change anything if in my examples I called the adding function `add` and not `+`? Compare: (add 1 3) vs. (+ 1 3). That's arguably even more humanized than 1 + 3. S-expressions aside, there's something else that I'd like to question: the usefulness of "1 + 3" in localization. Languages are really hard to get right if you apply maths and logic to them. Something that I really loved when I first saw it is Rust's pattern matching with guards. https://doc.rust-lang.org/book/patterns.html It looks like something that would be very useful for localization, perhaps more so than adding two numbers. While I'd like to allow the following to be possible (using the old syntax and skipping plurals): <lastVisit "Your last visit was {{ @Math.roundUp($days / 7) }} weeks ago."> ... I don't want to encourage localizers to write such code. First of all, if the developer passes $days, you should probably use days. OTOH, if some language uses weeks more often than days, then I think I'd like the localization community to create a common set of macros for this language so that the localizers can do the following instead: import('common'); <lastVisit "Your last visit was {{ _toWeeks($days) }} weeks ago."> The implementation can be thus hidden from the localizer while still keeping them in control of what's happening. The more I think about it, the more I'm convinced that possibly the only expression type that I'd like to be in a wide-spread use is the call expression: toWeeks(), prettyDate(), plural() etc. Which also works really well in S-expression, btw. Perhaps the gist of my thinking is this: we've designed the expression syntax such that it's too powerful for non-programmer-localizers (whom we want to encourage to only use the call expression) and not convenient enough for the programmer-localizers: the limitation of a single expression per body is troubling and our ternary-if syntax is cumbersome. I posit that we have two target audiences with different needs. If the expression syntax is going to be used by the few programmer-localizers, I question the decision to implement a complex syntax which is difficult to parse and has complex precedence rules. My proposal to use S-expressions was an attempt to work around this: make the expression syntax very general and lean, so that it's still possible to encode complex logic, but at the same time don't invest time and resources into maintaining it. > Semantical structures: > > This is one of the basic design principles I had way back when. > > There's no semantics to hashes. > I like the simplicity of this approach :) I think the need for semantics arose when we started thinking about tools like compare-locales and the social contract between the developer and the localizer. We wanted to understand if hash members were or were not part of the social contract. Do you have more thoughts on this? Related to this is my blog post on the asymmetry of L20n: http://informationisart.com/21/ > There's a tad of anti-Perl here, in that, if I can rule out an alternative > way of implementing stuff, I'd rule it out. > That's a really good rule to keep in mind in general, I like it. > Note, from a POV of "let's have a string per thing", requesting the same > entity for B, kB, mB etc, is already a premature optimization. But it's > also OK in practice, so I don't think we should spend to much effort to > create a white theory for it. > Hmm, I'm not sure I agree here. You're right that it's a bit an optimization and that the developer could also choose the unit on their side and then use one of the predefined translations corresponding to that unit (did I understand you right?). But OTOH, I feel like it would be better if the developer passed a raw value into the translation which the localizer can take and transform at will. For instance, suppose there's a language which increases the unit denomination on a off-by-one order of magnitude cadence, so: 3B, 30B, 300B, 3000B, 30KB, 300KB, 3000KB, 30MB, 300MB, 3000MB, 30GB etc. This is possible if we leave the choice of the unit to the localizer. The same applies to dates. -stas _______________________________________________ tools-l10n mailing list [email protected] https://lists.mozilla.org/listinfo/tools-l10n
