Re: [RFC] moving translations off sheets ?
- From: Cyrille Chepelov <chepelov calixo net>
- To: dia-list gnome org
- Subject: Re: [RFC] moving translations off sheets ?
- Date: Sat, 9 Jun 2001 18:13:32 +0200
Le sam, jun 09, 2001, à 09:05:11 +0800, James Henstridge a écrit:
It acts as a small wrapper around the gettext build scripts
(po/Makefile.in.in), adding support for extracting and merging from
various other formats. It should be trivial to add support for dia sheet
files, and once that is done, the strings in the sheet files will make
their way into the dia.pot file and be handled by translators just like
any other string.
Mmmmhhh... Looks like it does what my code does (but in a more generic way).
My little script (attached here) is more crude: it just snarfs all strings
and dumps them in a C file (I was too chicken to attempt merging stuff into
dia.pot myself :-) ). Unfortunately, that means that the message's location
identification is to be lost.
It seems that all what's we need to make xml-i18n-tools accept .sheet files
is to pipe two or three lines of xml-i18n's M4 file into sed
's/xml/sheet/g', do what's written in the README file, rip the translations
out of current sheet files (my tool can do that, so that current
translations can be manually merged into .po files), and sprinkle
translation files with underscores (though the exact place where underscores
are expected by xml-i18n-merge isn't crystal-clear).
We could use xml-i18n-tools for dia.desktop, too. That wouldn't be bad.
However, having xml-i18n-tools in the build process means that dia won't be
buildable on Debian "potato" without also recompiling xml-i18n-tools for
potato beforehand (same as for libunicode anyway).... I'm not sure it's
really a problem.
As part of dia's build process, it calls the xml-i18n-tools merge program
which merges translations back into the sheet files from the po files (it
may even be able to do a conversion to utf8 -- I haven't checked all the
details).
gettext can be told to re-encode the messages into UTF8: it's just a call to
bind_textdomain_codeset(PACKAGE,"UTF-8") between calling bindtextdomain() and
textdomain(). In fact, I've just committed this (under
UNICODE_WORK_IN_PROGRESS).
-- Cyrille
--
Grumpf.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]