On Thu, Dec 20, 2007 at 12:48:45AM +0000, Peter Clifton wrote: > I added internationalisation (via the intltoolize infrastructure) to > libgeda, in order to translate the mime registration XML file. > > BUT.. > > This I think this gives an issue for Debian. > > LC_ALL=C ../intltool-merge -x -u -c ../po/.intltool-merge-cache ../po > geda.xml.in geda.xml > > Then (assuming a translation), the .mo files will be installed as > "libgeda.mo" under the appropriate directory. > > How will this work if Debian allows multiple .so versions installed > side-by-side? (I expect the translation files will clash). > > Is there any president for this? > > Can we ship the latest libgeda.mo in libgeda-common, and just accept the > fact that the translations will only work for the latest installed > version? > > Should we try to prepend soversion to the name for translations?
Lots of library packages appear to include translation files. Glancing at a few: GTK+ keeps its translations in the libgtk2.0-common package. There's gtk20.mo for gtk+ 2.0, and gtk+.mo for gtk+ 1.2. glibc's translations are in the separate locales package. Dependencies ensure a pretty tight match between versions. Obviously soname transitions are pretty rare here so it's not clear what would happen. libgksu2-0 includes translations in the same package, and lots of other binaries that would conflict with a newer version. There's also a libgksu1.2 which has files named differently. So, I can't reach a conclusion from the above. I guess the translations should go in libgeda-common, and we just accept version skew. Or I tighten up the dependencies to ensure it can't happen (unless the soname can be embedded in the .mo filename). Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
