Closed rodionmoiseev closed 12 years ago
I support your idea! Also, is it possible to allow such definitions like en_US, en_UK, etc. taking into account both the language and the country rather than just the language only?
Thanks! Sure, you would be able to do that, because annotations can be bound to any Locale
object, which you may define as new Locale("en", "US")
or even new Locale("en", "US", "someDialect")
.
See how the default annotations are bound for reference: https://github.com/rodionmoiseev/c10n/blob/master/core/src/main/java/c10n/annotations/DefaultC10NAnnotations.java#L43
I've already knew about Locale(). Sorry that my suggestion is not so direct: can it be done for annotations like @en_US, @en_UK, etc.?
Sure! Just declare your own annotation:
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface en_US {
String value();
}
and bind it to the right locale, somewhere in your configuration:
bindAnnotation(en_US.class).toLocale(new Locale("en", "US"));
Got the most features to work, except the @C10NResource
(automated suffixing with _en, _ja, etc.). This will be tricky to implement with the current architecture due to the fact that all translations have to be loaded and saved at proxy initialisation time (i.e. C10N.get(MyInterface.class)
-time), but we only have the information about the current locale at this time, and cannot preload translations for other locales. This approach itself needs to be revised in order to allow to implement this feature completely. Therefore, I am closing this issue for now and will reopen it as another request if there is enough demand for it.
Edit: The internal resource path should look like intRes="com/example/resources/file.txt"
(as opposed to com.example.resources.file.txt
. I have updated the original issue post to reflect this.
Inspired by https://developers.google.com/web-toolkit/doc/latest/DevGuideClientBundle#I18N
API draft: