Project

General

Profile

Feature #9903

Make LUA-Scripts translateble

Added by Tobias Jakobs about 5 years ago. Updated over 2 years ago.

Status:
Fixed
Priority:
Medium
Category:
Lua
Target version:
Start date:
04/12/2014
Due date:
% Done:

100%

Affected Version:
2.0.0
System:
all
bitness:
64-bit
hardware architecture:
amd64/x86

Description

LUA-Scripts need a system to make the UI visible strings translatable.

History

#1 Updated by Tobias Jakobs almost 5 years ago

I've looked a little bit around an VLC uses Lua too and has gettext support:
An VLC Lua-Script, that uses gettext:
https://www.videolan.org/developers/vlc/share/lua/intf/cli.lua

And I think this is the git commit:
http://git.videolan.org/?p=vlc.git;a=commit;h=16cb266cb6f46c62213d0a5723b21a11110267b9

Perhaps that helps.

#2 Updated by Jérémy Rosen almost 5 years ago

a little, but taht's just exporting "_" and "_N" to lua.

That would replace a string with its translated version, but it wouldn't help getting the strings translated in the first place. The hard part is integrating lua source code with gettext to add the lua strings to the .po files.

#3 Updated by Tobias Ellinghaus almost 5 years ago

Tobias, do you happen to know how GIMP handles translations for scripts and plugins that are not shipped by GIMP and are therefore not translatable in GIMP's own translation files?

#4 Updated by Tobias Jakobs almost 5 years ago

From http://developer.gimp.org/README.i18n

Localization of third-party plug-ins

Third-party plug-ins (plug-ins that are not distributed with GIMP)
can't have their messages in the gimp-std-plugins textdomain. We
have therefore provided a mechanism that allows plug-ins to install
their own message catalogs and tell GIMP to bind to that
textdomain. This is necessary so that GIMP can correctly translate
the menu paths the plug-in registers. Basically the plug-in has to
call gimp_plugin_domain_add() or gimp_domain_plugin_add_with_path()
before it registers any functions. Have a look at the script-fu
plug-in to see how this is done in detail.

#5 Updated by Tobias Jakobs over 3 years ago

I'm just checking some old bug reports. Is this bug still open or is it fixed in the 2.0 branch?

#6 Updated by Tobias Ellinghaus over 3 years ago

  • System set to all
  • % Done changed from 0 to 50
  • Status changed from New to In Progress
  • Affected Version set to 2.0.0
  • bitness set to 64-bit

You can now use darktable.gettext to translate strings that are also used in darktable itself. If you ship your own .mo you can even use that, I never tried it myself though.

#7 Updated by Tobias Jakobs over 3 years ago

I've tested darktable.gettext and it works fine with darktable 2.0
Next on my list is to figure out how to create and use .mo files.

If everyone else is interested, the documentation is here:
http://www.darktable.org/lua-api/index.html.php#darktable_gettext

#8 Updated by Tobias Ellinghaus over 3 years ago

Create a .po file (maybe gettext or intltool can even grab those from your .lua file) and compile it into .mo with msgfmt -v foo.po -o foo.mo.

#9 Updated by Tobias Jakobs over 3 years ago

I've tested it and created an example script:
https://github.com/supertobi/lua-scripts/blob/gettext/contrib/gettextExample.lua

It works fine.

#10 Updated by Tobias Jakobs over 3 years ago

  • Status changed from In Progress to Fixed
  • % Done changed from 50 to 100

#11 Updated by Roman Lebedev over 2 years ago

  • Target version set to 2.2.0

Also available in: Atom PDF