rodionmoiseev / c10n

A Java library, focused on making internationalisation more modular, easier to evolve and maintain, robust-to-change and IDE-friendly without excess of external tools.
Apache License 2.0
67 stars 10 forks source link

Loading locale-sensitive external resources #2

Closed rodionmoiseev closed 12 years ago

rodionmoiseev commented 12 years ago

Inspired by https://developers.google.com/web-toolkit/doc/latest/DevGuideClientBundle#I18N

API draft:

@C10NMessages
public interface MyMessages{
  //locale mapped external file resources (or http, etc) 
  @En(extRes="file:///absolute/path/text.txt")
  @Ja(extRes="file://../relative/path/text.txt")
  String textFileContents();

  //Defer to ResourceBundle-like locale resolution 
  // (e.g. look for text_ja_JP.txt for Jp locale)
  @C10NResource(extRes="file://absolute/path/text.txt")
  String textFileContents2();

  //Access internal (in-the-jar) resources
  @En(intRes="com/example/text.txt")
  @C10NResource(intRes="com/example/text.txt")
  String internalResourceContents();
}
eclectice commented 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?

rodionmoiseev commented 12 years ago

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

eclectice commented 12 years ago

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.?

rodionmoiseev commented 12 years ago

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"));
rodionmoiseev commented 12 years ago

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.