Re: [XNap-Commons-Devel] I18n class

[Steffen P. <ste...@gm...>]

Hi,

> 1. Wir tun es nicht: Sprich I18n wird eine Klasse, die instanziiert wird
> und der Benutzer mu=DF sich selbst statischen access zu seiner benutzten
> Klasse verschaffen. Das m=FC=DFten wir dann auch in einer internen Klasse=
 f=FCr
> unsere resourcen machen.

Eigentlich war die Idee genau das zu vermeiden...

> Vorteile: ein bi=DFchen code ersparnis, keine unvorhergesehenen Probleme,
> weil die gleichen Keys in verschiedenen bundles verschieden =FCbersetzt
> werden, die Autoren aber nichts voneinander wissen.

Wenn ich mir den XNap anschaue, ist Codeersparnis meisst Ausrede f=FCr eine=
=20
schlechte Architektur...

> 2. Wir verwalten eine Liste von ResourceBundles, die nach den values
> durchsucht wird.

Ja, f=E4nde ich gut. Auch wenn es das Problem der Key=FCberlappung nicht l=
=F6sst.=20
Wobei sich doch zu diesem Zweck die trc() Methode benutzen liesse?=20

Wir k=F6nnten es auch =E4hnlich den loggern machen:

 private static I18n i18n =3D I18nFactory.getI18n(Foo.class);

Dann k=F6nnte man =FCber die class den ResourceBundle Context bestimmen.

Steffen

=2D-=20
Steffen Pingel - ste...@gm... - http://steffenpingel.de