Re: l10n architecture proposal available for comments

Rimas Kudelis wrote:
> Axel Hecht wrote:
>> Rimas Kudelis wrote:
>>> Axel Hecht wrote:
>>>> Rimas Kudelis wrote:
>>>>> Do you intend to support Grammatical cases [1] in any way? If yes,
>>>>> then how do you see it?..
>>>>>
>>>>> [1] http://en.wikipedia.org/wiki/Grammatical_case
>>>>>
>>>>> RQ
>>>> Yes, it works pretty much like the gender example in
>>>> http://people.mozilla.com/~axel/l20n/js-l20n/sample-01.html.
>>>>
>>>> If you create a sample output similar to one of the js examples I di=
d, I
>>>> can create a corresponding lol file to demo that.
>>>>
>>>> Sadly, neither German nor English really show this off canonically, =
so I
>>>> didn't do an example for that yet.
>>>
>>> OK, here's an example. From Microsoft Windows XP. Every user has a "M=
y
>>> Documents" folder there. Now in English, you can see "Jane Doe's
>>> Documents" for user Jane Doe, "Jack Daniels' Documents" for user Jack
>>> Daniels etc.
>>>
>>> Meanwhile in Lithuanian, to be gramatically correct, it cannot be
>>> "Rimas Kudelis' dokumentai" or "Rimas' Kudelis' dokumentai" or "Rimas
>>> Kudelis dokumentai" or anything like that. It has to be "Rimo Kudelio
>>> dokumentai".
>>>
>>> And your gender example would sound like this:
>>>
>>> Gerb. p. Kudeli,
>>>
>>> =C5=A1is tekstas lokalizuotas
>>>
>>> J=C5=ABs u=C5=BEsisak=C4=97te vien=C4=85 prek=C4=99.
>>>
>>> Name: Kudelis
>>> gender: male
>>> Items: 1
>>> Language: Lietuvi=C5=B3
>>>
>>> Now, do you think such DYNAMIC casing would be possible?
>>>
>>> RQ
>> Probably still somewhat simplified, but here it goes:
>>
>> <owner: "Rimas Kudelis"
>>  othercase: "Rimo Kudelio"
>>  gender: "male">
>>
>> <myDocuments: "${owner.othercase} dokumentai">
>>
>> Of course, you could have myDocuments depend on the gender of owner, f=
or
>> example.
>>
>> The tricky part comes when you actually realize that you want to get
>> "owner" from the user settings, at which point you probably bite a
>> bullet here, as I doubt that a user likes the idea of entering his nam=
e
>> in all genders, nor do I expect that there's a descent machine logic t=
o
>> guess the grammar for a name.
>=20
> You're right. But we're discussing L10n 2.0 here, so why not dream a
> little? ;)
>=20
>> Additional caveat, you don't really know whether the name of owner is
>> actually a lithuanian name or not, which might impact it, too.
>=20
> I think, every language has certain rules how to form cases. Ideally,
> our machine logic should at least work with the names of the context
> language, i.e., if Lithuanian rules should at least work with
> Lithuanian names (and they could apply some general casing, or no
> casing, for names that don't grammatically fit into Lithuanian).
>=20
> However, I think this also requires that we can specify some exceptions=
...
>=20
>> Like, what would happen to "Axel Hecht" in this case?
>=20
> This could be "Axelio Hechto dokumentai", for example. OR "Axel Hecht
> dokumentai".
>=20
>> Simply shows that "Axel's Documents" is a i18n bug. :-)
>=20

If we'd actually specify something turing complete, we could create=20
macros to process language mangling for names, but really, that's tough.

But yes, there is going to be a general section on "classes" in l20n,=20
and we should talk about people there, too.

Note, I would expect the attribute name to be the Lithuanian name for=20
the grammar case, so if I had a German name in a database, filled in=20
with German grammar cases, I expect the attributes logic to fallback to=20
the main string, so I guess even my sample code would return

Axel Hecht dokumtai

for that case. But I haven't checked, obviously.

Axel