Thomas Beale wrote: > It is clearly true that with a number of translations the archetype will grow > bigger, and initially (some years ago) I thought separate files might be > better as well. But I really wonder if it makes any difference in the end - > since, in generating the 'operational' (aka 'flat') form of an archetype that > is for end use, the languages required (which might still be more than one) > can be retained, and the others filtered out. I don't think gettext would deal > with this properly - the idea that an artefact can have more than one language > active. > > The other good thing about the current format (which will eventually migrate > to pure dADL+cADL) is that it is a direct object serialisation, and can be > deserialised straight into in-memory objects (Hash tables in the case of the > translations). > > Anyway, I think that we need to carefully look at the requirements on this > one, before leaping to a solution... > > - thomas > > One problem with the current way is that regional translations (e.g. en-us) are not treated any different than language-only translations (e.g. en). Essentially I believe 'en-us' should only carry the changes from 'en' - falling back to en if a code is not defined in en-us.
This doesn't mean that I am supporting separate files for this reason (as it should be possible to do this with the current one file approach), it's just another issue to consider when looking at the requirements) Sebastian
