With the number of documentation translations growing, the current system becomes less and less sustainable: if I now update an English tutorial, translators will have lots of trouble spotting the changes and updating their translations accordingly. It basically amounts to manual comparisons, which means the translations are likely to almost always be out of sync with the original.
How to fix this? I thought about the switch element:
http://www.w3.org/TR/SVG11/struct.html#SwitchElement
Inkscape needs to support it (it doesn't yet) at least for the systemLanguage attribute. Then, all translations of a tutorial can be stored in one file. A translator would select each text obejct (they will need to be converted to flowed text objects, by the way) and use a command to add an alternative for his language, then type the translation. Illustrations would be shared across all languages. This way, if a new section is added but not translated yet, users of a non-English language will still see this section in English, which is better than not seeing it at all. Inkscape could provide additional help by storing the last-edited timestamps in switch'ed objects, so that a translator could find sections where the original is more recent than a translation.
What do you think of this idea?
Hi,
if I now update an English tutorial, translators will have lots of trouble spotting the changes
Inkscape needs to support it (it doesn't yet) at least for the systemLanguage attribute. Then, all translations of a tutorial can be stored in one file.
What do you think of this idea?
It's a good idea. KDE documentation files are already created in a similar way: some tool extracts the textual data from the English documentation into PO files (one paragraph of documentation text becomes one PO-string IIRC) which translators can translate in the usual way, and then those PO files are used to build the language-specific documentation files.
Arpad Biro
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
bulia byak wrote:
Inkscape needs to support it (it doesn't yet) at least for the systemLanguage attribute. Then, all translations of a tutorial can be stored in one file. A translator would select each text obejct (they will need to be converted to flowed text objects, by the way) and use a command to add an alternative for his language, then type the translation. Illustrations would be shared across all languages. This way, if a new section is added but not translated yet, users of a non-English language will still see this section in English, which is better than not seeing it at all. Inkscape could provide additional help by storing the last-edited timestamps in switch'ed objects, so that a translator could find sections where the original is more recent than a translation.
There's an XML format for internationalization that we might also want to look at. TMX
Among other things, it's setup for collecting sets of translations (as opposed to being designed for holding only a single set of l10n data, as some others are). And since it's XML, we can play with XSLT to get to/from SVG.
El lun, 02-08-2004 a las 17:47, Jon A. Cruz escribió:
bulia byak wrote:
[...]
There's an XML format for internationalization that we might also want to look at. TMX
Among other things, it's setup for collecting sets of translations (as opposed to being designed for holding only a single set of l10n data, as some others are). And since it's XML, we can play with XSLT to get to/from SVG.
This is a great idea, were it not that there are not many (at least that I know of) open source tools that manage tmx data very well.
Personally I am far more used to working with po files (just like the ones we use for UI translation) and there's at least three good open source tools I can use to translate them; gtranslator (GTK), KBabel (KDE) and poedit (wxWindows, for Linux and Windows).
I suggest that, for immediate comfort, use the gettext/intltools approach, but keeping an eye on tmx, xliff for future use.
Thanks for your time,
On Sun, 2004-08-01 at 18:20, bulia byak wrote:
What do you think of this idea?
I think we need to support switch
but,
I'm curious if we can't solve this problem using intltool. I did the help on intltool-extract:
--type=TYPE Specify the file type of FILENAME. Currently supports: "gettext/glade", "gettext/ini", "gettext/keys" "gettext/rfc822deb", "gettext/schemas", "gettext/scheme", "gettext/xml"
There is that type field that seems to pull strings out of an XML file. I'm not sure that it would work in this case... anyone know any more about this?
--Ted
Ted Gould <ted@...11...> wrote in news:1091591851.3194.54.camel@...446...:
I'm curious if we can't solve this problem using intltool. I did the help on intltool-extract:
--type=TYPE Specify the file type of FILENAME. Currentlysupports: "gettext/glade", "gettext/ini", "gettext/keys" "gettext/rfc822deb", "gettext/schemas", "gettext/scheme", "gettext/xml"
There is that type field that seems to pull strings out of an XML file. I'm not sure that it would work in this case... anyone know any more about this?
Yes, intltool can handle XML files. You basically just have to prefix each localisable element with a '_'. Example:
<text>...</text> becomes <_text>...</_text>
It's similar for attributes.
On Sat, 2004-08-07 at 07:36, Karl Ove Hufthammer wrote:
There is that type field that seems to pull strings out of an XML file. I'm not sure that it would work in this case... anyone know any more about this?
Yes, intltool can handle XML files. You basically just have to prefix each localisable element with a '_'. Example:
<text>...</text> becomes <_text>...</_text>
It's similar for attributes.
I think we would need to localize text in the XML file, not elements or attribute names (which in most cases would be a very bad idea).
-mental
MenTaLguY <mental@...3...> wrote in news:1091945146.21698.207.camel@...4...:
<text>...</text> becomes <_text>...</_text>
It's similar for attributes.
I think we would need to localize text in the XML file, not elements or attribute names (which in most cases would be a very bad idea).
You misunderstand. It's the element content that gets localised, not the element name. So the above example would generate a POT file containing:
msgid "..."
On Sun, 2004-08-08 at 09:45, Karl Ove Hufthammer wrote:
MenTaLguY <mental@...3...> wrote in news:1091945146.21698.207.camel@...4...:
<text>...</text> becomes <_text>...</_text>
It's similar for attributes.
I think we would need to localize text in the XML file, not elements or attribute names (which in most cases would be a very bad idea).
You misunderstand. It's the element content that gets localised, not the element name. So the above example would generate a POT file containing:
msgid "..."
Ahhh, ok.
participants (7)
-
Arpad Biro -
bulia byak -
Jon A. Cruz -
Karl Ove Hufthammer -
Lucas Vieites -
MenTaLguY -
Ted Gould