Script messages not translated
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| Inkscape |
Low
|
jazzynico |
Bug Description
The scripts error messages are not translated in the dialog box, even when they are in the po files.
The problem is that an extra \n is added to the message (see src/extension/
description: | updated |
Changed in inkscape: | |
milestone: | none → 0.47.1 |
Changed in inkscape: | |
milestone: | 0.47.1 → 0.48 |
Changed in inkscape: | |
assignee: | nobody → JazzyNico (jazzynico) |
status: | New → In Progress |
description: | updated |
jazzynico (jazzynico) wrote : | #2 |
jazzynico (jazzynico) wrote : | #4 |
Doesn't work on Windows.
And doesn't work when the message has several individual strings (see JessyInk extension).
Only works on Linux (and probably OSX) with one string messages.
It really needs a better fix. Postponed to 0.49.
Changed in inkscape: | |
milestone: | 0.48 → 0.49 |
status: | Fix Committed → In Progress |
ScislaC (scislac) wrote : | #5 |
JazzyNico: Is this still being actively worked on (the in progress status)?
jazzynico (jazzynico) wrote : | #6 |
> Is this still being actively worked on (the in progress status)?
Yes, it's still in my 0.49 todo list. It's just not high priority...
jazzynico (jazzynico) wrote : | #7 |
Fix committed revision 11546.
Tested successfully on Windows XP and Ubuntu 11.04.
I've modified the strategy so that the messages are translated in the python code and not in script.cpp (using stderr to translate variable content is just not possible).
It should now work with almost all the messages. The remaining untranslated strings are mainly due to incompatibility between the their content and gettext in the python files, and will be worked on later.
jazzynico (jazzynico) wrote : | #8 |
New patch.
Should work better now and not break the extension system when no translation is available...
jazzynico (jazzynico) wrote : | #9 |
jazzynico (jazzynico) wrote : | #10 |
New patch committed revision 11551.
Tested successfully on Windows XP, Seven, and Ubuntu 11.04.
Work in progress for OSX.
su_v (suv-lp) wrote : | #11 |
> Tested successfully on Windows XP, Seven, and Ubuntu 11.04.
> Work in progress for OSX.
Based on the information in bug #1024851 (duplicate of bug #1024325), I don't think not really fixed for the other platforms either (in bug #1024851 python-based extensions failed the same way on Ubuntu 12.04 has did the command line version built on OS X).
jazzynico (jazzynico) wrote : | #12 |
> I don't think not really fixed for the other platforms either
Confirmed. Forgot to write that I'm going to test on Debian testing soon.
jazzynico (jazzynico) wrote : | #13 |
Apart from the operating system issues, the current implementation is still not satisfying because translating everything in inkex.py doesn't work when the string as %s, %d, etc. placeholders. I'm working on something different, but it requires changes in every python file that needs to be translated, and affects the way imported extensions (jessyink, gcodetool) should be written.
The idea is that the extensions import a common init_localization module and use it to find the translation file (the same way inkex is used when path manipulation is needed).
jazzynico (jazzynico) wrote : | #14 |
New patch attached.
A new localize() function has been added to inkex.py and called from the translatable extensions.
To make a extension translatable, you now need to remove:
import gettext
_ = gettex.gettext
and add:
import inkex (if not already imported)
inkex.localize()
Texted successfully on Windows XP and Debian Wheezy (and yes, the correct locale file is used if I use a local build instead of the packaged version!).
su_v (suv-lp) wrote : | #15 |
Patch '425202-
Error messages returned from extensions script are not translated (tested with LANG="fr_FR.UTF-8" and running the extension 'Perspective' with two circles selected).
[1] will test with packaged version later: at the moment, the patch does not consider osx packaging yet (platform: darwin).
With the osx-packaged version, the environment variable is set in the launcher script inside the relocatable application bundle (not in 'src/main.cpp'):
<http://
su_v (suv-lp) wrote : | #16 |
If I change the fallback to 'False' on line 64 of the patched 'inkex.py', extensions fail with the same error message as reported in bug #1024325.
Since the current solution (with fallback=True) fails gracefully (i.e. doesn't translate nor crash), it's kind of ok - but then the old version could be used as well without changing every python script bundled with inkscape, and adding new requirements for extension developers.
su_v (suv-lp) wrote : | #17 |
With the patch applied, the extensions used for the 'Help' menu to open the URL in the web browser fail:
Exception in thread Thread-1:
Traceback (most recent call last):
File "/Volumes/
self.run()
File "launch_
webbrowser.
NameError: global name '_' is not defined
su_v (suv-lp) wrote : | #18 |
Additional information re OS X:
If I copy the code block for Windows in 'inkex.py', change the condition for the platform to match 'darwin', and then launch the command line version with explicitly setting 'INKSCAPE_
However, AFAIU it should not be required for a normal "linux-style" configured and installed version of Inkscape to depend on this variable which originally was introduced for packaging only (where the location of the locale files might not be in the same as the compiled-in absolute paths based on ${prefix} used with './configure', and change if the packaged version is self-contained and relocatable).
jazzynico (jazzynico) wrote : | #19 |
> With the patch applied, the extensions used for the 'Help' menu to open the URL in the web browser fail
Fixed...
jazzynico (jazzynico) wrote : | #20 |
> AFAIU it should not be required for a normal "linux-style"
Confirmed. But since you need to set envs in a launcher in order to launch Inkscape correctly, I guess the behavior is quite different.
Would it work is you set INKSCAPE_LOCALEDIR in your launcher script, with ${prefix} automatically calculated depending on the launch directory ?
jazzynico (jazzynico) wrote : | #21 |
> adding new requirements for extension developers.
Just for your information, old style extensions don't break the extension system. They just don't translate. But since lots of them don't translate with 0.48.3.1, it's not a big annoyance.
We just need to be sure what we release is good enough so that we won't need to change the whole extension directory again the next Inkscape version.
su_v (suv-lp) wrote : | #22 |
> But since you need to set envs in a launcher in order to
> launch Inkscape correctly, I guess the behavior is quite different.
No, you misunderstood. I _am_ using the "standard" command line version of Inkscape: it is configured, compiled and installed exactly like on linux (eg with ./configure --prefix=
My issue is with normal builds on OS X, where none of the proposed patches works to translate those error messages.
su_v (suv-lp) wrote : | #23 |
> Would it work is you set INKSCAPE_LOCALEDIR in your launcher script,
> with ${prefix} automatically calculated depending on the launch directory ?
The variable is already in use and set (correctly) in the launcher script (see my link in comment #15), because the same variable is also required for the main 'inkscape-bin' binary to locate the locale files inside the self-contained relocatable application bundle.
jazzynico (jazzynico) wrote : | #24 |
Just tested on Debian Wheezy, with a local build (nothing in /usr/bin or /usr/local/bin), and extensions translation doesn't work. The .mo file needs to be in the PATH (manually copying the file to /usr/share/
jazzynico (jazzynico) wrote : | #25 |
IMHO it's worth releasing the patch in 0.49, even if it works for the packaged version only. There's an impact on the scripts because we move the translation initialization from the scripts themselves to the inkex module, but the positive point is that no changes (except in inkex) will be required if we modify the way we initialize python translation later.
Any objection?
su_v (suv-lp) wrote : | #26 |
> even if it works for the packaged version only.
I see no point in doing so tbh: packaging for osx is likely to change fundamentally when moving to using the native backend of GTK+ - and there is no existing solution for getting python-based extensions to work at all with the newer proposed packaging based on gtk-mac-bundler (WIP).
Unless that major change to all python scripts and inkex.py is useful and required for other platforms (i.e. all linux distros), and works reliably without actually falling back to assumed default locations for po/mo files (which might be installed or not), …
su_v (suv-lp) wrote : | #27 |
>> even if it works for the packaged version only.
>
> I see no point in doing so tbh: (…)
Sorry if my earlier comment caused more confusion than clarification - maybe you only referred to Windows packages (which IIRC is the only case supported by the latest available patch - as mentioned in earlier comments it neither worked with default builds on OS X (installed into custom prefix), nor with OS X packages based on current packaging scripts). Fixing this for Windows only is ok of course…
jazzynico (jazzynico) wrote : | #28 |
The patch fixes the issue on Windows (packaged AND local builds) and GNU/Linux (at least on Debian Wheezy, packaged version only, and Ubuntu - not tested if it works with local builds). I'm going to test again on Ubuntu in case there's something different in the way the translation base is handled.
jazzynico (jazzynico) wrote : | #29 |
Third patch. This one also works on Ubuntu, and should work on OSX as well.
A different env (PACKAGE_
jazzynico (jazzynico) wrote : | #30 |
Removing patch v3 (still doesn't work, invalid test...)
jazzynico (jazzynico) wrote : | #31 |
This one should be ok.
su_v (suv-lp) wrote : | #32 |
> Third patch. This one also works on Ubuntu, and should work on OSX as well.
- works with linux-style installation on OS X (into custom prefix)
- fails with OS X package [1]
I'm fine with committing '425202-
---
[1] tested with new OS X package built based on r11743 plus three patches from private branch to make current packaging scripts work on OS X 10.7 Lion (with MacPorts installed into custom prefix):
<http://
<http://
<http://
Problem: '$PACKAGE_
INKSCAPE_LOCALEDIR
/Volumes/
PACKAGE_LOCALE_DIR
/Volumes/
On 07/10/2012 18:16, ~suv wrote:
> INKSCAPE_LOCALEDIR
> /Volumes/
> PACKAGE_LOCALE_DIR
> /Volumes/
Attaching debug extension used to verify the content of these variables
as seen in the environment of the spawned python process.
jazzynico (jazzynico) wrote : | #34 |
Patch v3 committed revision 11749.
Thanks for your help and tests, ~suv!
Changed in inkscape: | |
status: | In Progress → Fix Committed |
su_v (suv-lp) wrote : | #35 |
Patch to make it work for OS X packages too (based on current X11-based packaging). The python code very likely could be optimized - what I tried to implement:
if platform is 'darwin' then
if $INKSCAPE_LOCALEDIR is set
use it
else
if $PACKAGE_LOCALE_DIR is set
use it
else
use fallback
jazzynico (jazzynico) wrote : | #36 |
Patch from comment #35 committed revision 11767.
Great, now it works for everybody! Thank you for the OS X patch!
> The python code very likely could be optimized
Maybe we could find something more pythonic. But at least it works as expected and the code is not ugly, thus I suggest we optimize it after 0.49 is out.
su_v (suv-lp) wrote : | #37 |
@JazzyNico - could you please review the changes in r11749 to 'share/
On Ubuntu 12.10, opened a simple CDR file works with Inkscape 0.48.3.1, but fails with a (local) trunk build. AFAICT r11749 breaks usage of UniConvertor 1.1.4 (e.g. on Ubuntu 12.10 [1]), because 'cmd' is reset to 'None' even after having successfully found 'uniconvertor' in the tests right above.
Note: AFAICT UniConvertor 1.1.4 doesn't have 'uniconv_run()', and fails if called via the python command on line 61:
<http://
-----
[1] <http://
su_v (suv-lp) wrote : | #38 |
Proposed diff, tested with r12031 on Ubuntu 12.10
jazzynico (jazzynico) wrote : | #39 |
@~suv - I did something very ugly here, indeed...
Thanks for the patch, feel free to commit!
su_v (suv-lp) wrote : | #40 |
Fix committed in r12032.
Changed in inkscape: | |
status: | Fix Committed → Fix Released |
Fix committed in bzr revision 9371.
Please test!