Yon,
let me clarify: I did not assume that the .adp file would contain the default locale. It can contain any string you like in any language. As long as it is unique in it's meaning (something you can safely asssume, as we are not talking about words but sentences and these tend to be different from language to language). But we'd have to store the default locale of the package in the apm {And yes, I assume that one package will be written in one language at a time. But if this assumption is too restrictive, you could add the locale as a parameter of the TRN tag}. And it is not only about .adp files. We might even end up changing .tcl files depending on locale (just take cal-dayview.tcl as an example, doesn't work in Germany, we don't use am and pm).
For each language (including en_US) there would be an .adp file. My reasoning started with performance implications (hitting the database with every TRN tag) and ended with different layout (which also includes different views of calendars, different positioning of items if you read from right to left [There was this cool ad where you had a pile of dirty cloths on the left, a laundry machine in the middle and clean cloths on the right. Interesting if one reads right to left 😊]. But does it really matter why we do it as long AS we do it 😊 ?
As for the seperator, the only thought behind it was that the seperato could be part of the locale as well as the filename (as all the people are using it). And me personally hates filenames like edit-page_de_DE.adp. But as I said, it is only something to think about not necessarily to implement (aka. random thought).
Last but not least, how would the TRN tag work automatically on the script? Where would the TRN tag be placed in the first place? My assumption was that we take what we have and put a TRN tag around all hardcoded text within the .adp files (In the form <TRN LOCALE=en_US>Life is beautiful</TRN> {with or without the locale definition}). Everything between the TRN tags would be used as a key like I described above. One other option I heard was using identifiers like we use for database queries. But I don't see the difference (except that the text might be larger), but one looses the ability to work on the default .adp without storing data for the text one wants to use in the database. Well, and this still does not cope with the fact, that we have sentences which occur in multiple packages. Giving them identifiers will result in the same sentence being stored in the DB multiple times (as one will not be able to coordinate the identifier naming across the packages so that the same sentence gets the same identifier in dotLRN, survey and e-commerce).
Malte
P.S.: Could we get a spell checker installed for the bboard. It's a shame to read how many errors I make :.(
