Comments on: The L20n Format Shootout

By: Robert Kaiser

Robert Kaiser — Thu, 27 Aug 2009 18:38:58 +0000

YAML also seems to run into problems with strings that should start or, what we have more frequently in our code, end with a space. Also, multi-line strings are hard to represent from what I see, but again, this is something we have quite frequently in our code.
That said, I’m generally not a fan of indentation that is relevant to evaluating the code, but that might just be me. I think it’d be confusing enough for a number of localizers, though.

I’m not necessarily a fan of all details in terms of punctuation choices in the proposed LOL format, but I think it’s the most simple to understand for the person editing such a file, i.e. the localizer (though I’m sure with time there will be tools to abstract it away from the non-technical localizers, there are always more technical ones who at least want to look at the files, maybe directly edit them).

By: Jeremy Hiatt

Jeremy Hiatt — Wed, 26 Aug 2009 19:07:09 +0000

Thanks everyone for your comments.

@Dave: You’re right that LOL is the most effective format for expressing these objects. The issue is that using a proprietary format makes it that much harder to port l20n to other platforms, so we wanted to gather some feedback on that. Still, I’d have to agree that JSON and YAML really don’t work particularly well and that LOL looks like the best choice.

@johnjbarton: I’d like to hear more about why you don’t like DTD. Is it the angle bracket syntax, or something else? As far as your properties suggestion, I do like a few things about that format, especially that it doesn’t use a lot of punctuation. However, that also means that it’s clunky to express an object with a lot of properties, requiring a lot of repetition of the prefix. One issue with the example you proposed is that it can’t be parsed unambiguously, since the intended index could be appName or appName.gender. That’s not to say that there aren’t other ways to make this work in a properties-like format, but ultimately it seems like it would end up being quite confusing. I’d be interested to see you prove me wrong, though!

@Sebastian, Archaeopteryx: I’m going to pass the blame on to Axel Hecht here, who wrote the example. I don’t speak German, so I’m not really qualified to weigh in on this one. He’d also be the one to ask about the choice of beer as the example. Thanks for bringing this up!

By: Archaeopteryx

Archaeopteryx — Tue, 25 Aug 2009 18:17:20 +0000

As Sebastian already indicated: “Ein hübsches” is neutral, “Eine hübsche” female.
Should we be concerned why you use alcoholic products to demonstrate the user of gender?

By: Sebastian Redl

Sebastian Redl — Tue, 25 Aug 2009 13:58:18 +0000

“Ein hübscher ${appName}.”
“Eine hübsche ${appName}.”

By: johnjbarton

johnjbarton — Tue, 25 Aug 2009 05:30:20 +0000

Nothing similar to DTD please. I did not see anything about just using property files, eg
complex.indices.appName.gender.male = Ein hübscher ${appName}s.
complex.indices.appName.gender.female = Ein hübsches ${appName}s.

appName.gender.male = Jägermeister

jjb

By: Dave

Dave — Tue, 25 Aug 2009 01:20:34 +0000

I see no reason to not just pick the simplest format that’s written for the job. Why bother trying to hack something else into doing this? JSON would be a mess here and YAML doesn’t look much better. LOL seems the obvious choice to me.