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
