Lucian Muresan wrote:
...
On long term, its probably best to move i18n out of the c source and into editable language definition files that can be loaded on runtime. (I think thats what Klaus meant with 'language files'.)
Yes, that's what I meant. But let's do this in version 1.5.x.
Klaus
That beeing said, Klaus & everyone, what would you think about letting me give it a try? I think and I hope I'll be able to provide a patch in few days, with all existing translations migrated to the new aproach and adapted makefiles (maybe until this weekend, depending on spare time), in the meantime we could discuss the concept, maybe I'll have questioons for few details (maybe there are issues other than spare time or priorities which made you plan this for 1.5.x). Well, in the end we'll see if it's good or not, but we might have the chance to workout the breakage in this i18n matter only once and already now (as I said, I think I'll be able to do it myself, so it's up to me to find the time, and I'll promise I'll yell or let it be if I happen to get stuck, you won't have to wait for this if you already plan a feature-freeze for releasing 1.4, I only think we could give it a shot, it might turn out good enough for having it merged). But please tell me if there is ablsolutely no interest for this now.
Lucian
I definitely will not change the i18n methods for version 1.4. You are, of course, free to do whatever you like, but none of this will go into version 1.4. I also won't adopt the sorting patch, since it would break plugins. I18n in version 1.4 will be exactly as it is right now.
I have a few things that I still want to finish for 1.4, and i18n changes is none of them.
Sorry, gotta draw the line somewhere...
Klaus