Hi,
After installing Inkscape from current CVS, the following menu entries appear in English in my (otherwise) localized environment:
_Edit _View _Layer _Object _Path _Text Effects _Help
File/_New File/Open _Recent Help/Tutorials
The rest of the UI appears localized. Could someone please test this on his localized system?
Arpad Biro
__________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Arpad Biro schrieb:
Hi,
After installing Inkscape from current CVS, the following menu entries appear in English in my (otherwise) localized environment:
...
The rest of the UI appears localized. Could someone please test this on his localized system?
Arpad Biro
same in german. :-(
Adib.
On Sun, Sep 25, 2005 at 11:26:55AM -0700, Arpad Biro wrote:
After installing Inkscape from current CVS, the following menu entries appear in English in my (otherwise) localized environment:
_Edit _View _Layer _Object _Path _Text Effects _Help
File/_New File/Open _Recent Help/Tutorials
The rest of the UI appears localized.
I believe this is because those strings don't appear anywhere in the source code (other than in one big string of XML in menus-skeleton.h), and consequently these strings aren't appearing in the po files.
pjrm.
On Mon, 2005-09-26 at 17:39 +1000, Peter Moulder wrote:
The rest of the UI appears localized.
I believe this is because those strings don't appear anywhere in the source code (other than in one big string of XML in menus-skeleton.h), and consequently these strings aren't appearing in the po files.
Yeah, and I'm not sure what to do with the problem. It is the same one that we have with the .inx files, but I think this comes to a different solution. I'm thinking about making the whole XML file translatable... I realize that this has some issues, let me try to put pros and cons here:
Cons - Translators have to know and create valid XML in a particular format - Translators can significantly change the menu layout in Inkscape, and may create usability issues. - I really wanted to make it so that Effects would dynamically modify the internal XML for menu placement, that'd be impossible if all menus are not direct translations (which isn't always reasonable, see below)
Pros - All strings can be translated - Menus can be moved with the translation. I'm having a hard time trying to explain this, and I think it is partially because I'm basically mono-lingual. Here's my best effort. Let's say Inkscape had a "Free" menu where we had things that were zero cost and personal freedoms (I'm trying here). If you were to translate this into Spanish directly, the menu would have to be the "Gratis y libre" menu. It would make more sense in a Spanish translation to have two menus.
I'm not sure how the pros and cons weigh out here, I'd love to know what other people think. I think the 0.43 fix is to add "N_()" to the strings in menu-skeleton.h, which I think will still cause them to concatenate (anyone know?)
--Ted
El mar, 27-09-2005 a las 00:01 -0700, Ted Gould escribió:
On Mon, 2005-09-26 at 17:39 +1000, Peter Moulder wrote:
The rest of the UI appears localized.
I believe this is because those strings don't appear anywhere in the source code (other than in one big string of XML in menus-skeleton.h), and consequently these strings aren't appearing in the po files.
Yeah, and I'm not sure what to do with the problem. It is the same one that we have with the .inx files, but I think this comes to a different solution. I'm thinking about making the whole XML file translatable... I realize that this has some issues, let me try to put pros and cons here:
Cons
- Translators have to know and create valid XML in a particular format
- Translators can significantly change the menu layout in Inkscape, and
may create usability issues.
- I really wanted to make it so that Effects would dynamically modify
the internal XML for menu placement, that'd be impossible if all menus are not direct translations (which isn't always reasonable, see below)
And why not treat them as a different thing. Not *everything* has to be in a .po file. I know things should be made easy for translators because they are not always _technical_ people, but hey, this is free software (as in free beer), we can also make an effort and try to understand what we're doing. Translating an xml file is no reverse engineering, and there are many tools out there able to extract translatable strings and put them back where they belong (read xml2po, open-language-tools, etc.). I think the translators should be informed of the files they have to translate in order to have a 100% translation and a little how-to on how to do it. - the .po file - the tutorials in svg (now the open-language-tools support svg, yay!) - the menu.xml file
Just my opinion, Lucas
Pros
- All strings can be translated
- Menus can be moved with the translation. I'm having a hard time
trying to explain this, and I think it is partially because I'm basically mono-lingual. Here's my best effort. Let's say Inkscape had a "Free" menu where we had things that were zero cost and personal freedoms (I'm trying here). If you were to translate this into Spanish directly, the menu would have to be the "Gratis y libre" menu. It would make more sense in a Spanish translation to have two menus.
I'm not sure how the pros and cons weigh out here, I'd love to know what other people think. I think the 0.43 fix is to add "N_()" to the strings in menu-skeleton.h, which I think will still cause them to concatenate (anyone know?)
--Ted
On Tue, 2005-09-27 at 09:37 +0200, Lucas Vieites wrote:
- the .po file
- the tutorials in svg (now the open-language-tools support svg, yay!)
- the menu.xml file
I think this is a good idea. Translate it like the tutorials where the only think in the po file is the name of the translations file. I'm thinking the precedence should be (for LANG=jp):
~/.inkscape/menus.jp.xml ~/.inkscape/menus.xml /usr/share/inkscape/menus.jp.xml /usr/share/inkscape/menus.xml
Anyone see any problems with that?
--Ted
On 9/28/05, Ted Gould <ted@...11...> wrote:
On Tue, 2005-09-27 at 09:37 +0200, Lucas Vieites wrote:
- the .po file
- the tutorials in svg (now the open-language-tools support svg, yay!)
- the menu.xml file
I think this is a good idea. Translate it like the tutorials where the only think in the po file is the name of the translations file. I'm thinking the precedence should be (for LANG=jp):
~/.inkscape/menus.jp.xml ~/.inkscape/menus.xml /usr/share/inkscape/menus.jp.xml /usr/share/inkscape/menus.xml
Anyone see any problems with that?
Could anyone please enlighten me why this custom solution is better than the usual PO way?
Alexandre
El mié, 28-09-2005 a las 17:07 +0400, Alexandre Prokoudine escribió:
On 9/28/05, Ted Gould <ted@...11...> wrote:
On Tue, 2005-09-27 at 09:37 +0200, Lucas Vieites wrote:
- the .po file
- the tutorials in svg (now the open-language-tools support svg, yay!)
- the menu.xml file
I think this is a good idea. Translate it like the tutorials where the only think in the po file is the name of the translations file. I'm thinking the precedence should be (for LANG=jp):
~/.inkscape/menus.jp.xml ~/.inkscape/menus.xml /usr/share/inkscape/menus.jp.xml /usr/share/inkscape/menus.xml
Anyone see any problems with that?
Could anyone please enlighten me why this custom solution is better than the usual PO way?
The po will be translated as always. It seems that there are problems integrating the strings in the menu.xml file in the .po so a solution is to translate them separately.
Alexandre
This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Alexandre Prokoudine wrote:
On 9/28/05, Ted Gould <ted@...11...> wrote:
On Tue, 2005-09-27 at 09:37 +0200, Lucas Vieites wrote:
- the .po file
- the tutorials in svg (now the open-language-tools support svg, yay!)
- the menu.xml file
Anyone see any problems with that?
Could anyone please enlighten me why this custom solution is better than the usual PO way?
I guess I saw the big advantage as translators being able to use XML tools for the translation. I don't believe that they'd get that otherwise. It seemed like it matched with the way that the tutorials were being done today also.
I'm thinking that overall, the menus are going to have to be translated as a group. I don't care if it is a separate file or a string in the PO file.
What is best for translators?
--Ted
I'm thinking that overall, the menus are going to have to be translated as a group. I don't care if it is a separate file or a string in the PO file.
What is best for translators?
I must admit I don't care if the menu strings are in some XML files BUT i'd prefer having all the strings for the application in 1 po file : it's much more comfortable.
Regards,
Matiphas.
On 9/28/05, Ted Gould <ted@...11...> wrote:
I guess I saw the big advantage as translators being able to use XML tools for the translation. I don't believe that they'd get that otherwise. It seemed like it matched with the way that the tutorials were being done today also.
I'm thinking that overall, the menus are going to have to be translated as a group. I don't care if it is a separate file or a string in the PO file.
What is best for translators?
Well, I don't know how XML nature of a file to be translated could help me do my job faster and easier. PO works fine for me.
As for tutorials, the best way to translate them would be temporary conversion to PO the way it's done in KDE i18n project.
Alexandre
Alexandre Prokoudine schrieb:
On 9/28/05, Ted Gould <ted@...11...> wrote:
...
What is best for translators?
Well, I don't know how XML nature of a file to be translated could help me do my job faster and easier. PO works fine for me.
As for tutorials, the best way to translate them would be temporary conversion to PO the way it's done in KDE i18n project.
Alexandre
Q: that means that the translation of the tutorial remains in the po file that will be deliverd ? Even the tutorial is translated and converted to the different svg's :-?
I also would like to know how we/I can add strings to the/a po that are not in the c-source ? This can increase the number of translations for the win32 installer. I then can simply read the strings out of a po file and have to maintain only the logic and not translations.
Thanks,
Adib.
On 9/29/05, Adib Taraben <taraben.a@...50...> wrote:
Q: that means that the translation of the tutorial remains in the po file that will be deliverd ? Even the tutorial is translated and converted to the different svg's :-?
No. How it works is:
1. Convert an XML markup(p)ed file (customized DocBook/XML in case of KDE) to PO file with a special utility that breaks the whole text into multiply PO entries sentence by sentence.
2. Translate.
3. Commit to CVS/SVN. . 4. When changes to original text get committed, your PO file is automatically updated. Changed text becomes a fuzzy entry in PO file. New text becomes untraslated entry. You can easily navigate from one fuzzy/untranslated entry to another in KBabel. Compare it to xmldiff output ;-)
5. For release PO files are converted back to XML and, in case of Inkscape, could be then converted to SVG.
I also would like to know how we/I can add strings to the/a po that are not in the c-source ?
I'm not sure I'm really helpful here, but this is exactly what happens to inkscape.desktop file.
Alexandre
El jue, 29-09-2005 a las 01:31 +0400, Alexandre Prokoudine escribió:
On 9/29/05, Adib Taraben <taraben.a@...50...> wrote:
Q: that means that the translation of the tutorial remains in the po file that will be deliverd ? Even the tutorial is translated and converted to the different svg's :-?
No. How it works is:
- Convert an XML markup(p)ed file (customized DocBook/XML in case of
KDE) to PO file with a special utility that breaks the whole text into multiply PO entries sentence by sentence.
Translate.
Commit to CVS/SVN.
.
When changes to original text get committed, your PO file is
automatically updated. Changed text becomes a fuzzy entry in PO file. New text becomes untraslated entry. You can easily navigate from one fuzzy/untranslated entry to another in KBabel. Compare it to xmldiff output ;-)
- For release PO files are converted back to XML and, in case of
Inkscape, could be then converted to SVG.
I'd like to point out that there's a fairly recent tool available for translatoin of svg files: Open Language Tools (https://open-language-tools.dev.java.net/). These used to be a Sun inside project but they released it a few months ago. It's very suitable for translation of XML files (it also supports a variety of other formats) and recently some committed a filter for SVG. The great thing about these tools is that they have a fairly good translation memory, which is useful when updating a translation. I think it's easier to use than the conversion to and fro.
Cheers, Lucas
I also would like to know how we/I can add strings to the/a po that are not in the c-source ?
I'm not sure I'm really helpful here, but this is exactly what happens to inkscape.desktop file.
Alexandre
This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Here's what I'm thinking right now. How about we put it in the .po file for now, for 0.43. And then, we start looking at the best ways to handle XML files. I would really love it if someone would take and run with this, the .inx files need to be translatable also. I good solution for all of them would solve many problems.
Does anyone see adding it to the po file as a problem today?
--Ted
Ted Gould pensò:
Yeah, and I'm not sure what to do with the problem. It is the same one that we have with the .inx files, but I think this comes to a different solution. I'm thinking about making the whole XML file translatable...
No, just mark strings translatable and generate the po with xmlpo. This is the usually recommended solution...
I realize that this has some issues, let me try to put pros and cons here:
Cons
- Translators have to know and create valid XML in a particular format
- Translators can significantly change the menu layout in Inkscape, and
may create usability issues.
- I really wanted to make it so that Effects would dynamically modify
the internal XML for menu placement, that'd be impossible if all menus are not direct translations (which isn't always reasonable, see below)
- Translators cannot use tools as gtranslator, kbabel or online tools that work only with po files; - The translation of the XML cannot be easily checked by scripts like the ones in the gnome.org CVS, so the translators have to check manually for changes in the po and other statistics;
Pros
- All strings can be translated
I'm not sure this is a pro. From a traslator point of view it is not. It make easy to translate string that have to be not translated. Just mark string to be translated translatable and edit the generated po file...
- Menus can be moved with the translation. I'm having a hard time
trying to explain this, and I think it is partially because I'm basically mono-lingual. Here's my best effort. Let's say Inkscape had a "Free" menu where we had things that were zero cost and personal freedoms (I'm trying here). If you were to translate this into Spanish directly, the menu would have to be the "Gratis y libre" menu. It would make more sense in a Spanish translation to have two menus.
This makes the ui change based on the locale, which I think is not a good idea...
participants (8)
-
unknown＠example.com -
Adib Taraben -
Alexandre Prokoudine -
Arpad Biro -
Emanuele Aina -
Lucas Vieites -
Peter Moulder -
Ted Gould