Getting Started

[Tony Kay]

Hi,

I've gotten clearance to put our code under the MIT license...so we can start to work on this.

Out current production library is Java, and I'll need to maintain compatibility there; however, I'm hoping to accomplish the following:

- Ability to use the library as it is in Java

- A Scala library wrapper on top of it that adds superior support to Scala

- An xgettext compiler plugin for scalac v2.10 and above for pulling out strings, and supports easy extension of the i18n methods it understands (like xgettext does)

- A module for using it in Lift (which is where I need it next)

The current library has some hard internal dependencies (on how the Locale is chosen at runtime), so I'll want to generalize that a bit, and it also has a few internal things like a "default" data format that is non standard that I'll need to continue to support as a setting.

Finally, the current library has a number of functions for helping embed in HTML...I think Scala's support for XML will encourage a better interface on these that output XML literals instead of strings.

I'll have the code up on GitHub soon. I want to come up with a decent name for the i18n stuff that can be promoted to the Java and Scala community...any thoughts? I was thinking something along the lines of Gettext-Wrapper...something that indicates a strong association with the GNU Gettext library (which is what I use underneath in Java) and the integration of Java i18n features (like DataFormat).

Do you want to keep the xgettext compiler plugin separate? That is doable...all that would need to happen is more general support for being able to tell it what functions are used for translation.

Also: Maven, or SBT?

Tony

[Tony Kay]

I've created the github repo:

https://github.com/awkay/easy-i18n

I can always rename it.

I think we'll end up with multiple projects.

- The Java base library

- The Scala wrapper for the library

- The Scala Compiler plugin

- The Lift module I want to write to integrate with Lift

I'm adding the unedited source of the i18n stuff now to the Java project, which will be Maven-based.

Tony

[Tony Kay]

OK. The repo has the base source in it...I have not stripped all of the internal weirdness yet, but it compiles and most of the tests run. We do some weird stuff with dates here, so I'll have to touch up that code.

Also, we hard-code the message bundle loading, which I'll need to generalize.

See the tests...they show a good deal of the functionality.

Tony

[Ngoc]

Thanks. I think there will be multiple projects.

Do you load .po files? I have created this project:
https://github.com/ngocdaothanh/scaposer

[Tony Kay]

Yes, I am aware of your project.

I use po files, but through the existing GNU gettext library. They have a Java library that can convert po files to a MessageBundle format that their Java library can use to provide gettext support. Their utilities do a nice job of creating optimized class-file versions of the PO files that are very fast to do lookups against (with one caveat..missing translations are slow, which I've hand-fixed in my own version of their code).

So, the workflow is:

- Write your code using the library calls (e.g. I.tr("message to translate"))

- Run xgettext on the code (GNU's utility has a Java mode already)

- Run the various other utils to merge messages, etc....also provided by GNU

- Run GNU msgfmt on the resulting .po files in Java mode (again, provided by GNU). This outputs .class files that could be used by Java or Scala.

- Put these .class files in a JAR and package them with the app

So, the only thing I'm missing for all of this to work really well with Scala is something that can extract the messages from Scala (e.g. your compiler plugin) to a POT file....the existing GNU utilities can do the rest.

I'll be adding documentation as quickly as I can type :)

Tony

[Tony Kay]

OK. I've gotten a version up that is starting to be my vision of a usable external library. I still have a bit of work to do to make it nicely general, but all of the tests pass, and I've generalized most of the things that had internal dependencies...I still need to fix our "default date format" hacks into a more general form.

I've also written a good deal of documentation. Note that some of that documents things I'm _planning_ to do and haven't completed yet. The LanguageSetting stuff is currently half baked...and language setting providers don't even exist yet.

If you get a chance, look through the GitHub Wiki, the javadocs, and the I18NTests.java file. Let me know what you think, and if it still looks like something you'd like to help and integrate your compiler plugin with.

In particular, I have a Scala port that tweaks a few minor things, but I think a full-blown Scala wrapper that does nice things for Scala users would be ideal.

Tony