This is one of the use cases for using fragment bundles. A fragment bundle
is sharing the same class loader as the host bundle, so you get the same
behaviour as with a plain Java project.
Am 16.01.2017 4:42 PM schrieb "Tim Ward" <t...@telensa.com>:
What's the recommended approach to loading strings for I18N?
Without using OSGi, one might create a bunch of .properties files, and load
them as needed with
ResourceBundle.getBundle( "basename", loggedInUsersLocale )
with the basename[_...].properties files on the class path. With a suitably
chosen class path one can then drop in .properties files at run time to add
new language translations[#].
When using OSGi, dropping files into "the class path" is obviously somewhat
more complicated, and in any case it would be more in keeping to drop in
bundles rather than raw .properties files, wouldn't it?
What are the common patterns for doing this with OSGi? - the specific
requirement here seems to be to add a new language without a system
rebuild: putting a bunch of .properties files into an I18N bundle which
gets rebuilt for new languages (ie rebuilding a bundle not the entire
system) would probably work but off the top of my head sounds less
attractive than a pattern which involves dropping in a new bundle for a new
language. Or should I be looking at the fileinstall service? (So many ways
to approach things ...)
[#] give or take the caching, which I haven't experimented with yet
--
Tim Ward
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
