Forum: Weblog comments

It is kind of unfair to say that "the actual code is much shorter", since you in one example have used the if statement and in the other have used the conditional operator. The php-example might have looked like:
print(sprintf(gettext($postCount < 1? 'no comments': ($postCount == 1? '%s comment': '%s comments')), $postCount));

If you wanted to write the php in a more "lol way", it might look like:
blog.php
print(l20n_commcnt($postCount));

blog_de.php
function plural0($n) { $a = func_get_args(); return $n == 0? $a[1]: ($n == 1? $a[2]: $a[3]); }
function l20n_commcnt($n) { return plural0($n, "keine Kommentare", "$n Kommentar", "$n Kommentare"); }

Also, personally I don't like the "<" and ">" to enclose the functions in the lol-file. It might jsut be my eyes that go into xml-parsing mode and throw an error when they meet programming syntax :). I think, I would just end the functions with ";" if anything are really needed. Also why would you use "name: (args) -> { body }" in one function definition and "name[args]: body" in the other? Or should the second be read as "name body" with the "[index]: [element, element, ...]" be kind of a reversed array indexing similar to "[element, element, ...][index]" in eg. javascript? In that case it seems odd not being able to name the formal arguments.

Hmm... I posted to early. Let me try again:

blog_de.php
function plural0($n, $zero, $one, $many) { return $n == 0? $zero: ($n == 1? $one: $many); }
function l20n_commcnt($n) { return plural0($n, "keine Kommentare", "$n Kommentar", "$n Kommentare"); }

My point was that even though lol is a domain specific language, there is a lot of superficial syntax. Eg. you could just have used the php/javascript syntax with "function" removed (since all top level statements in lol are functions), return removed (a la perl) and "$" removed from php (since they of course aren't needed) and just add curly braces around the variables embedded in strings. That would make the example simpler and shorter.


BTW, Re: "Second, there is no "original string" in the source, just an ID ("comm_cnt"), it actually doesn't matter which language I'm doing first, while writing the code, as L20n doesn't care."
Proponents of po-files might argue, that it is actually a good thing to have the english (or any other) version as a guide as to how the string is used.

For your questions about the lol syntax, you should read the L20n wiki page I linked in the first paragraph. BTW, I didn't invent that syntax, I'm just using it in those examples.
For the if vs. conditional operator, you're basically right though it would harm code readability (and as long as you want to use xgettext, only plain strings can be inside a gettext() function, so that or its abbreviation _() has to be used three times).
And I think you're missing the fact that lol is a language-independent format, which is not only important for getting localization tools working on top if it, but also for e.g. Mozilla's use in C++, JS and XUL.
The "original string" argument can be just countered with the need to always have a first lol file even for the "original" language, which can easily be used as a guide for localizers.

Robert, you should really change your gettext example to actually use plurals, i.e., ngettext, as your code is not localizable into Polish, for example.

You'd still want to take out the 0 as special case, though, as the standard gettext plural forms would suggest to use

Sie haben 0 Kommentare

instead of

Sie haben keine Kommentare.

And yikes on that ';', thing, that's VETOed. It's just a huge mistake, try to find out what's happening when you miss out on a ';', it has horrible error recovery and reporting side effects.

Thanks for the reply

> read the L20n wiki page
Yes, I found that after I'd posted the comments. But even though the syntax is described there, the semantics don't seem to be. And it doesn't explain the need to "reinvent the wheel" (e.i. not stealing as much a possible from other good languages).

> BTW, I didn't invent that syntax, I'm just using it in those examples.
Okay, I didn't mean to knock on you.

> For the if vs. conditional operator, you're basically right though it would harm code readability (and as long as you want to use xgettext, only plain strings can be inside a gettext() function, so that or its abbreviation _() has to be used three times).
But my examples don't use gettext? And after lol, it is apparently allowed to embed translations inside programming languages (since, lol is a programming language -- it looks turing complete).

> And I think you're missing the fact that lol is a language-independent format, which is not only important for getting localization tools working on top if it, but also for e.g. Mozilla's use in C++, JS and XUL.
The fact that the lol-language is supposed to be called from many different languages, doesn't dictate what syntax the lol-language should use. In particular it isn't an argument for inventing a whole new verbose syntax (to paraphrase a saying: the difference between good an bad programming languages is, that the good only steal from the best)

> The "original string" argument can be just countered with the need to always have a first lol file even for the "original" language, which can easily be used as a guide for localizers.
Well, then the localizers would need to look at and synchronize two files (the file they are working on and a reference, which ever that is).

Looking at other attempts and many discussions out there, there is a well defined line between stealing as much as possible and stealing as much as feasible. This might be just me picking at the PO-discussions, but whenever I hear a "but you could ...", this essentially comes with quite some additional (and non-possible) baggage.

I don't think that there is a whole lot of stuff to take from existing attempts on the surface, we're changing paradigms here. The paradigm shift is much more confusing if one makes it look like something different. That might be funky with letters like < or > or " or [, but there are only so many non-letter chars to pick from.

Not exactly sure what you mean here. And to clarify, L20n is not intended to be turing complete.

"Best" has nothing to do with good. "Best" is not an objective (?) criteria either, in particular when it comes down to localization architectures. There are no single target audience, too, I know at least three (architecture impls, software authors, localizers). "Best" is really bad. I stole whatever I found good, really, and put it into a legacy-free world. Again, I don't think that the l12y problems we're facing are solvable without a paradigm change, and that's the hard nut to sell. Everything beyond that is just personal taste.

Btw, I'm not sure if there's just one Anonymous posting here, so if you don't really have to, giving your name would help a bunch to distinguish one Anonymous from the other.