I wanted to slight modify webbrower_* extensions so that they directly bring to the web page in the relevant language when it exists. I thought the good way to do that would have been to give the address as a translatable parameter that is not set by the user, but I didn't find how to do that, it seems impossible.
I guess it is impossible, since there are several extensions for visiting a web page. Am I right ?
Do you have an idea to work around my problem ? Maybe using a parameter proposing the different languages to the user ?
Romain
On Tue, 2007-02-20 at 16:45 +0100, Romain Thouvenin wrote:
Do you have an idea to work around my problem ? Maybe using a parameter proposing the different languages to the user ?
Can extensions get the LANG environment variable? Would that work for determining the language? I believe they should have the same environment as the one Inkscape was called in.
--Ted
On 2/20/07, Ted Gould <ted@...11...> wrote:
Yes they can. But according to the FAQ, the way Inkscape determines the language is sytem-dependent : LANGUAGE variable on Linux, LANG on Windows (which has a different meaning on Linux, but still can be use for that purpose, and some lproj files for Mac (I don't know anything about Mac). So, even if it seems feasible (at least for linux and windows), isn't that a pity that extensions do this independently ?
But I don't know how hard it would be to change .inx DTD, Ted's solution may well be the best for now.
Romain
Bob Jamison <rwjj@...127...> writes:
I don't know either, but I know the following:
$ LANG=dz inkscape
(inkscape:29081): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale.
(and Inkscape is in English). However, if I do
$ LANGUAGE=dz inkscape
then it comes up fine in Dzongkha.
Cheers Colin
On Tue, 2007-02-20 at 22:36 +0100, Romain Thouvenin wrote:
So, even if it seems feasible (at least for linux and windows), isn't that a pity that extensions do this independently ?
Well, it's a pity that scripts have to parse the XML file too :)
But I don't know how hard it would be to change .inx DTD, Ted's solution may well be the best for now.
It isn't as much hard, as I'm looking for the "right" solution. Here's what I see as issues right now.
Goal: Localize webpages for help menus.
Issues:
1) Need to figure out the locale that Inkscape is running in. 2) Need to find out if the webpage is even translated into that locale.
I was hoping that we could have a generic way to handle 1 that would avoid having the translators have more work. But, in thinking more about it, I think the really hard problem is 2. It is totally possible with that Inkscape could be running in a locale that doesn't have translated webpages.
I think for that, we'll have to get the translators involved in saying that the webpage is in a good state for that language. But, do we want them doing that in Inkscape itself, or on the webpage? If it was on the web with appropriate fallback, then we could "update" live, and users would get translations without having to update their Inkscape installations.
--Ted
On 2/21/07, Ted Gould <ted@...11...> wrote:
Parameters are given to extensions as arguments, there's no need to parse the xml. I was thinking about a way to do that without asking the user for the value of the parameter.
I agree we need the help of translators. Since it is possible to use gettext within a script (and it is easy to do), couldn't we include strings from extensions in po files ? In the script, we ask the browser to open _("http://.../FAQ"), and translators translate it in po files as "http://.../FrFAQ", deFAQ and so on. They do it only if there is a translation. I'll investigate that today.
Romain
On Wed, 21 Feb 2007, Romain Thouvenin wrote:
I'm not sure that is such a good idea. Scripts cannot easily be changed when they have already been shipped in a two year old version of Red Hat (and that is a simple example, software can be far longer lived and even less frequently updated than that). Better to point to a single place, preferably only places on the Inkscape website where we actually have the power to fix links and update content. Sure make it technically possible to localise the help string for documentation stored on the users computer but external links are hugely unreliable so it is better to minimise their use if at all possible.
participants (6)
-
Aaron Spike -
Alan Horkan -
Bob Jamison -
Colin Marquardt -
Romain Thouvenin -
Ted Gould