l10n for tool documentation

[tombentley]

Within Ceylon community we must have quite a few people whose first language is not English. All the ceylon tools (ceylon compile, ceylon doc etc) are (in theory) internationalized. We just need the localization.

As a first step, we could identify the languages we think we could actually do the l10n for and be prepared to maintain.

[lucaswerkmeister]

My first language is German, and I’d be happy to help out. Is there documentation on how to provide translations? I found several .properties files (src/com/redhat/ceylon/*/resources/messaget.properties, langtools/src/share/classes/com/sun/tools/*/resources/*.properties), but they seem to be kind of scattered around...

[tombentley]

Hi @lucaswerkmeister, there's no documentation as yet (it would be great if we could produce some as a result of doing the first translation). I think there are a number of parts to this:

1. All those messages.properties files contain messages produced by the tools. They are standard Java resource bundles that need translating. They are scattered around because they tend to live alongside the tool that emits that message. We could try to centralize them, though I don't see any particular advantages to doing that. Note that not all the tools are in ceylon-compiler, you also need to look at ceylon-js, ceylon-common and ceylon-runtime.
2. The English version of the tool documentation (i.e. what gets turned into HTML and man pages) is in the source code for each tool (in the form of annotations). The tools which generate the documentation look for appropriate resource bundles when generating their output, but there's no existing resources bundles to simply translate. I guess it would be helpful to have something (like an option to ceylon doc-tool) which produced the message bundle which corresponded to the embedded documentation, so there's a fully-formed message bundle ready for translation.
3. The typechecker currently isn't internationalized at all: All its messages are hard coded English. I guess we need to open an issue in ceylon-spec for that.
4. Finally, there are the messages the JVM compiler has inherited from javac. Those are in some properties files in the langtools directory of ceylon-compiler.

Even when we have all of these, we're going to have to deal with messages being changed, and making sure those changed messages get translated. I suppose we could use a label in the issue trackers for that, though that doesn't seem very robust.

[lucaswerkmeister]

I’ll look into this when the OBR (One Big Repository) merge is done, because this isn’t restricted to the Java compiler backend – it also applies to the typechecker, JS compiler backend, and possibly others.

[FroMage]

Moving to 1.2