[Mono-devel-list] [PATCH] Reworked unified Locale classes

[Kornél Pál]

>> I know that gettext () is widely spreaded on Linux but this does not have
>> to
>> mean that it is the best solution and the Class Library has it's own
>> infrastructure for globalization using identifier based resources and
>> culture based resource files.
>
> I have yet to be convinced that there are any benefits in using the
> identifier-based lookup of strings as opposed to the gettext-like
> system.

In the message you have quoted from there are all my reasons against gettext
() I did not wanted to copy the entire message but feel free to read it if
you need.

> * Gettext is well understood in the Linux world.

Identifier based localization is well understodd in the world of Windows and
.NET.:) But as I was to undersand both of these methods in no time I don't
think this could be a reason to use either of them.

> * There are existing tools to extract strings to be
>   internationalized.

If these tools are just extracting text marked "some text" from
GetText("some text") and are not doing automatik GetText insertion or any
other things with the code the will work with identifier based localization
as well but you will have to modify the files created by these tools by
adding the english text for each identifier.

> * There are plenty of localization tools: Emacs modes,
>   GUI editors, web-based collaboration frameworks.

I think this is not a problem because we can tell them that identifiers are
the original English text and English is a localized language. And a good
tool has to be able to show the texts in other languages to make translation
easiers.

> * Rosetta also has direct support for handling conflicts,
>   applying editorial control, pulling translations from
>   multiple projects to make translations suggestions.

As long as it does not do autotranslation the can be no problems because of
the reasons above. If it uses autotranslation I think with a minor
modification it can be made to be compatible with identifiers. Anyway there
are a lot of translation gears that have support for identifier based
localization.

> I think that identified-based frameworks have problems:

> * They require each identifier to be documented (we
>   need to do more work to start today).

You don't have to document them you simply have to use identifier in the
code and add an entry to the resource file with that identifier and an
English message.
And if you have a resouce file it's easier to use the same messages for the
same purposes insead of using a lot of variants of the same text.

> * If the documentation is not good enough, then
>   contributors must read the source code to figure out
>   what the problem is.

Translators has to look at the source code to find out in what context the
text is used because doing translation without knowing the purpose of the
text will lead to funny and unusable translations. And identifiers don't has
to be documented because source code itself is the documentation.

> * It is not clear when those keys require arguments, it
>   is common to see in the framework errors that are
>   lacking information, I do not remember one right now,
>   but they look like this:
>
> Invalid method `'

They look like this: Invalid method {0}

If you look at only "Invalid method {0}" you will have no ideawhat will be
used for {0}. It may be a single word a number or a whole sentence. So if
you want to do proper translation you have to look at the source code. But
for identifier base localization in the base (English) resouce file you will
have lines like this:

Invalid_method=Invalid method {0}

So you will see the English text as well. Entries to English resouce file
has to be added by developers but the text can be modified by anyone without
breaking compatiblity with any other languages. This is an advantage of
identifiers.

>   Where the maintainer did not know that an argument was
>   expected.

He will see "Invalid_method=Invalid method {0}" so he will know the number
of arguments. Of course he will not know the type of the arguments but he
would not know it even if he were see "Invalid method {0}=Invalid method
{0}". So this is not a difference.

So I think none of these issues are critical.

Kornél