>>>>> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
>> I propose a different solution, which is a mix of what you did and >> what I proposed earlier. >> >> 1/ use a clear notation for translators hints that does not risk to >> be used in normal code, like [[double brackets]] or /*C-style >> comments*/ Georg> I don't like this very much, because we limit the domain of Georg> translatable strings, but I think I would prefer the double Georg> bracket version if we are going to do it like this. I do not think that this is a problem in practice... we can also use <[weird brackets]>, or anything that comes to mind. >> 2/ Once a string has been translated, remove translators hints >> (using a regexp) if they are still present. >> >> It seems to me that this avoids nicely the use of a en.po. Georg> Why do you want to avoid it? The amount of code is almost the Georg> same as for your proposal. IMHO using en.po is a nice solution Georg> (I may say that, it is Angus' idea, not mine :-) ) I really do not like the idea to use en.po whereas the user has set for example LC_ALL=C. This really seems like a hack to me. Georg> Yes. See attached diff (undefine USE_EN_PO, parts of my Georg> previous patch are needed, too). The regex is preliminary, Georg> bacause like this I did not need to change the dialogs again. Georg> The same coarse timing method as above shows no difference Georg> above noise between a normal build, the method with en.po and Georg> your proposal. I would have used a regex like "^(.*)\\[\\[translation hint:.*\\]\\]$", in order to force the [[...]] to be at the end of the string, but basically this is the version I prefer. JMarc
