5

In Python/C++, I normally use _("string") for i18n string text.

for Java, I use bundle.getString("string"). Obviously, it is uglier than Python/C++.

How to write such code shorter?

Katriel
  • 120,462
  • 19
  • 136
  • 170
zhongshu
  • 7,748
  • 8
  • 41
  • 54
  • 2
    I think `bundle.getString("string")` looks better than `_("string")`. It actually tells you what it is doing. – Katriel Mar 10 '11 at 11:04

2 Answers2

7

Create your own method:

public String _(String key){
        return bundle.getString(key);
}

Or something similar. Underscore is a valid method name in Java. Of course, you can use any other single character, if you prefer, say l like localize.

So, now you can call it the same way as in Python.

Russ Hayward
  • 5,617
  • 2
  • 25
  • 30
Goran Jovic
  • 9,418
  • 3
  • 43
  • 75
  • so, how can I use _ everywhere， should I define this method in every class? If define _ in a util class, I must use util._(key), still long code ;( – zhongshu Mar 10 '11 at 10:13
  • 2
    @zhongshu: No, you don't have to. You can use `import static` to import that method alone in every class. Then you can use only method name, without class name. – Goran Jovic Mar 10 '11 at 10:14
  • @Goran, just what I want. Thanks. – zhongshu Mar 10 '11 at 10:30
  • The disadvantage of the static approach is that you will be forced to use a single global static bundle. This may cause problems if you want to apps to share the same VM, for example when running in a application server. – Russ Hayward Mar 10 '11 at 10:36
  • 2
    @Russ: Static variables are global per class loader, not per VM. If you are using an application server, all your webapps will have separate class loaders for their own classes. – Goran Jovic Mar 10 '11 at 11:01
  • That is usually true - however I have found class loader isolation to be imperfect. Maybe a better example would have been if any of the code needs to be used in another application. Using a static approach makes it far harder to integrate due to the hidden dependencies. The code also becomes harder to unit test. – Russ Hayward Mar 10 '11 at 17:04
  • @Russ: I generally agree with what you said. However, I doubt that anyone would want to reuse a i18n utility class. The properties file yes, but the class itself is so simple that it might as well be rewritten for later use. Also, why and how exactly would you unit test a localization method. It would be a little more than a test of HashTable class. Again, I agree with your observations but here it's really a case of [YAGNI](http://en.wikipedia.org/wiki/You_ain't_gonna_need_it). – Goran Jovic Mar 10 '11 at 18:20
  • @Goran: I was not thinking about reusing the utility class. The issue for me would be if you used the internationalised class in a different context and wanted control over its internationalisation mechanism. The same is true in a unit test, using a static method removes the ability to mock out the call to the bundle. All these things seem minor and a bit over the top at first - it is when the code gets reused and abused later that reducing static calls really pays off. – Russ Hayward Mar 10 '11 at 21:55
  • @Russ: Ah ok. Shortly put, you are talking about absence of polymorphism for static stuff. A perfectly valid point. Problem is indeed easily avoidable by using instance methods and not static ones. Anyway, – Goran Jovic Mar 10 '11 at 22:40
  • @RussHayward a solution to use non-static is to use dependency injection like Spring to inject your i18n instance. With the advent of (at-sign)Configurable you can even do this for new instances (classes/objects not managed by spring). – Adam Gent Apr 04 '12 at 02:39
1

Thats the way Java is, you can call it ugly, though.

I would pretty much stick with the Java convention and use the bundle.getString(...) version. :)

Adeel Ansari
  • 39,541
  • 12
  • 93
  • 133