On Tuesday 06 January 2009, CJN Fryer wrote: > matters QT3/4 and the elimination of the evil KDE (i18n? It's only a > translation engine! How hard can that be? ... (looks nervously from side to > side))
1) The old i18n() syntax changed radically. We used the converter tool other people had written and tested extensively on other projects to change to the new i18n() syntax, because it fixed thosands upon thousands of build errors for free. It worked really well, and I think I only had to go fix like five things by hand. 2) Find a KDE4 i18n() to Qt4 tr() porting guide. Nobody writes "how to turn your KDE project into a plain Qt project" porting guides, because we're probably the only project in the entire world of this size to ever do such a ridiculous thing, and the burden of figuring out how to translate the syntax is all on you, brother. 3) tr() uses a different format and different tools. All of our translators (including me; I'm currently maintaining two languages myself) are used to dealing with .po files, and know what to do with them. We either have to convert from .whatever to .po and back (which leads to a weird legacy format situation and a maintenance headache) or re-educate legions of translators and deal with all the growing pains (and rewrite all of the assorted HOWTO docs too.) 4) We also have to rewrite all of our own internal translation management tools to use the new format, and re-train developers on how to manage updates and stuff, many of which come in as patches or email attachments, and have to be shuffled around to get them to fit properly into place. 5) Either way, we have to re-train developers. Currently nobody is writing any new strings, and nobody much knows how to say things in either syntax, so this would be a good time to switch everything in that respect. Everybody has to learn a totally new syntax for dealing with plurals and other issues regardless. But if people get any time invested in learning the new i18n() (which is easier, because there are guides), it's going to be harder to push switching to tr() later. Also, as weird as the new i18n() is, it seems less alien to me than tr(), and I think we're up against a steeper learning curve going that route regardless. There are probably 6 and 7 and beyond too. This is an enormous problem. It can be solved, but can it possibly be worth it? Not for my time. It's bad enough we're having to deal with all the rest of this crap just to move sideways and backwards. This was one thing we could deal with almost for free, and free won hands down forty billion times over! -- D. Michael McIntyre ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
