The Bundle-localization header refers
to files containing the translations of headers.Based on this name, the
proper file is looked up in the bundle and its attached fragments.
However this lookup is not done for
fragments which makes the translation of fragments almost impossible. Indeed
because fragments can not have fragments, a fragment that need to be translated
must provide its translation up-front. This is pretty hard since most of
the time the translation are only provided later.
Here is a proposal that would workaround
this problem and allows for translation of fragments in a modular way.
The proposal simply consists in changing the lookup algorithm:
- instead of only looking in the fragment
itself, the localization file lookup should delegate to the bundle-host
to which the fragment is attached to. Therefore all the fragments would
be consulted then allowing to find the translation file of a fragment inside
of another fragment.
Bundle Fragment1 (fragment of A)
Bundle Fragment2 (fragment of A)
contains the files myFragmentLocalizationFile_en_us.properties,
Bundle-Fragment3 (fragment of A)
contains the files myHeaders_en_us.properties,
In this example Fragment2 provides the
translation for Fragment1, and Fragment 3 the translation for Bundle A.
Of course there is an infinite recursion
problem however one can believe that the people providing the NL fragments
are able to provide the translation for their fragment :-).
Fragments attached to several hosts:
Although fragments can be attached to
several hosts, the lookup of the translation file can only be done on any
Indeed if a fragment is attached to
several hosts, it is because all the hosts it can be attached to are compatible.
Moreover if a translation bundle is attached to a host, it should have
the same matching criterias (regarding bundle host selection) than the
fragment to which it provides translation for.