Boo

I also thought of it, and think we may support either GetText and ResourceManager.GetString() mechanisms, which the user chooses using command line options at compile time.

I think the best approach is to create some macro-magic in two similar pipeline stages that some command-line option inserts in the compiling pipeline...

Personal preference: I would prefer to have "internationalized string literals" denoted by a # prefix.

Same technique can be used that is used with BOO-1 and numeric literals.

I love this!
Marking string for internationalization is such a pain in most languages and also very dependent of the implementation behind.
We should think of an extensible API to handle this cleanly.

When a string _"test" is marked the compiler would replace the literal by a call to an ITranslatableStringHandler.GetString("test") method.

Boo.Lang.I18N.Globalization.SourceCulture as CultureInfo : culture of the marked strings (can be null for undefined).
Boo.Lang.I18N.Globalization.TranslationCulture as CultureInfo : if null will take the culture of the CLR else force translate to TranslationCulture if available.
Boo.Lang.I18N.Globalization.TranslatableStringHandler as ITranslatableStringHandler : the default could be a ResourceManager-based implementation, user can set this static property for using its own implementation (using Mono.GetText for instance).

Boo.Lang.I18N.ITranslatableStringHandler
GetString(original as string) as string
FormatString(original as (string), arguments as (object)) as string

Marked string interpolations would be handled by FormatString() with the string split between the arguments.

Just my 2 cents,

Is there any update/progress on this?

Seems there is none.

Are you willing to contribute?

Let's make it for 0.9

Isn't this achievable with the current feature-set, using macros or metamethods? I wouldn't want to add "noise" to the Boo core if the same functionality can be implemented externally...

Yes, a meta method in a separate library would do just fine.

It's not really doable with the current feature-set with the proposed _ prefix before strings - which is a common way to mark strings for internationalization in other languages, and much more elegant than a call to some static method somewhere for each literal string).

When boo.ometa is in, hence syntax extensions of this kind are possible, there won't be 'noise' since we can move that syntax extension into the Boo.I18N namespace
So that it does not forbid the use of _-prefix for other purposes (or another implementation) if desired.

Still, I think the value here lies into having a standard way to handle translatable strings in the language [1], with out-of-the-box resource-based implementation, while being able to plug pretty much any implementation to it (through ITranslatableStringHandler).

1: supporting simple strings like _"hello" is easy, but the goal here is to also support string interpolations automatically.

Well yeah I guess _("foo") is a valid temporary option until our parser allows just _"foo".

Still isn't a default ready-to-use tested implementation worthwhile?
A real (ie. useful) implementation needs, as proposed in the api, a way to set a source and destination language (that can be changed at runtime, with fallback to source language if a translation for one particular string is not present), support for string interpolations etc..