11:26 a.m.
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
11:40 a.m.
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.
12:39 a.m.
New subject: menus.xml and localization problems
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.
12:01 a.m.
New subject: menus.xml and localization problems
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
12:37 a.m.
New subject: menus.xml and localization problems
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
--
Lucas Vieites Fariña <lucas@...212...>
Web: <http://www.asixinformatica.com/users/lucas/>
Blog: <http://www.asixinformatica.com/blog/>
11:44 p.m.
New subject: menus.xml and localization problems
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
6:07 a.m.
New subject: menus.xml and localization problems
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
7:09 a.m.
New subject: menus.xml and localization problems
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(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
--
Lucas Vieites Fariña <lucas@...212...>
Web: <http://www.asixinformatica.com/users/lucas/>
Blog: <http://www.asixinformatica.com/blog/>
11:35 a.m.
New subject: menus.xml and localization problems
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
1:14 p.m.
New subject: menus.xml and localization problems
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.
1:40 p.m.
New subject: menus.xml and localization problems
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
2:18 p.m.
New subject: menus.xml and localization problems
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.
2:31 p.m.
New subject: menus.xml and localization problems
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
12:28 a.m.
New subject: menus.xml and localization problems
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:
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'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(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
--
Lucas Vieites Fariña <lucas@...212...>
Web: <http://www.asixinformatica.com/users/lucas/>
Blog: <http://www.asixinformatica.com/blog/>
12:17 a.m.
New subject: menus.xml and localization problems
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
5:34 a.m.
New subject: menus.xml and localization problems
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...
--
Buongiorno.
Complimenti per l'ottima scelta.
6635
days inactive
6641
days old
inkscape-devel@lists.inkscape.org
16 comments
8 participants
participants (8)
-
unknown＠example.com -
Adib Taraben -
Alexandre Prokoudine -
Arpad Biro -
Emanuele Aina -
Lucas Vieites -
Peter Moulder -
Ted Gould