Make i18n method names configurable

[lefou]

In Java/Scala-land, I would argue, tr, trn, ... are more common, at least in my projects. I currently still use xgettext which accept the method names with the -koption. Using scala-xgettext is not possible because of incompatible hardcoded method names.

[lefou]

Here is, what my I18n traits typically look like:

trait I18nMarker {
  def marktr(msgid: String): String = msgid
  def marktrc(context: String, msgid: String): String = msgid
}

trait I18n extends I18nMarker {
  def tr(msgid: String, params: Any*): String
  def trn(msgid: String, msgidPlural: String, n: Long, params: Any*): String
  def trc(context: String, msgid: String, params: Any*): String
  def trcn(context: String, msgid: String, msgidPlural: String, n: Long, params: Any*): String
  def locale: Locale
  def preparetr(msgid: String, params: Any*): PreparedI18n
}

trait PreparedI18n {
  def tr: String
  def notr: String
}

object I18n extends I18nMarker {
  def apply[T: ClassTag]: I18n = apply(Locale.getDefault)
  def apply[T: ClassTag](locale: Locale): I18n = ???
}

The preparetr is a convenience thing, which encapsulates the message and params and provides the formatted messages in translated (tr) and original (notr) version, which is handy e.g. for Exceptions.

[ngocdaothanh]

Sorry for not implementing what you need earlier.

Please see the new README:
https://github.com/xitrum-framework/scala-xgettext#configure-i18n-method-names

If there's anything, please let me know.
I'll release version 1.2 in a few hours.

[lefou]

Thank you very much.

Can there be more than one method for each type of message demarcation? E.g. the marktr method, which is used to tag a message for translation without translating it, should technically behave as the t (or tr) method, but currently it seems only one method, either t, tr or marktr, can be used.

[ngocdaothanh]

I'm curious: What's your use case with that feature?

Actually, t, tn, tc, and tcn are just markers to scala-xgettext. scala-xgettext is a compile time plugin, and used several times during your program development. It doesn't call the methods.

So I think you can do like this:

For example, you have tr and marktr (that does nothing).

When you want to extract i18n strings, use this scalacOptions:

Seq("your.I18n", "t:tr").map("-P:xgettext:" + _)

After extracting you get a i18n.pot file.

Then change "t:tr" to "t:marktr" and compile again, you get another i18n.pot.

You only need to merge (with Poedit, for example) the 2 files together to get the final result.

[ngocdaothanh]

I've just released version 1.2.
You can download it from Maven within around 1 hour.

[lefou]

The feature is required, to mark strings for translation without actually translating it. This can be necessary e.g. if you define the string before you have access to the translator, e.g. when using it in an object or some "static" location (like an Java enum). It is also handy, if you use the untranslated string internally, e.g. in the database, but want to translate it's presentation.

Of course, I can run the compiler with the plugin multiple times and can merge the catalogs, but this is a lot of extra work (for the compiler and in the toolchain). As xgettext directly supports this, I think, it could be a feature of scala-xgettext too.

[lefou]

On top of this, there is the preparetr method, which also needs to mark the string plus needs access to the translated and the untranslated string. That way, it can abstract from formatting. If you want to provide translated exceptions, it is a good idea to always provided the untranslated but formatted string in getMessage() but the translated one in getLocalizedMessage(). You can than easily create such an exception like this:

val msg = i18n.preparetr("Error was: {0}", errMsg)
throw new MyException(msg.notr(), e, msg.tr())

It's also useful to reuse the msg for log message (untranslated) and for user output (translated).

[ngocdaothanh]

Thanks for the explanation.
I'll implement the feature at #5.

[lefou]

Great. Thank you very much.