POC: translation done by darktable.

[TurboGit]

This is a POC on how Lua script translation could be handled directly in darktable.

The darktable part

• Add lua-scripts has a submodule in src/external

• Add all lua files into po/POTFILES.in

This will make it possible with the current main darktable translation workflow to also translate the scripts.

The Lua script part

• As proposed in this PR remove the gettext domain, use a common one to share as much as possible the strings across darktable and all lua scripts.

• Use common casing for all Lua strings. Indeed there is some string identical except for the casing. Again this is to share a maximum of string.

• Remove any spaces in start or end of strings, the layout must not be done in strings. I see for example "of " and some other cases.

Redesign

• As discussed in issue Some GUI proposal for the script manager #438 we also want to redesign the Lua script description to be more uniform and structured. Those description must be done using _('...") to allow for translation. Some description are quite big, I'm wondering if we want this in the dt tooltip or maybe a lite description in dt tooltip and a full description in main dt documentation. To be discussed.

• We probably want to have a string for the name of the module provided by the script. As I understand we use the script filename for the name today. This is not really user friendly, so better have a string for the name of the script which is displayed on the UI (as done for dt modules).

• The redesigned of the UI with standard button as already discussed.

@wpferguson : This is my current idea to make Lua scripts a first class citizen. Let me know how it sounds to you.

I hope I have not missed something, but at least with this POC I was able to translate Lua scripts in French.

[TurboGit]

@wpferguson : All this is quite some work, so if you agree with the general direction I'd propose to concentrate on the two scripts in this PR. The main script manager and the copy_paste_metadata plug-in. When (if) we can get this working properly then we'll have a clear idea of the transition for all others plug-ins.

[wpferguson]

same as above

[wpferguson]

change this line to gettext.bindtextdomain("darktable", dt.configuration.locale_dir)

[TurboGit]

I may be missing something, but why is it better than removing the line? What did I broke?

[wpferguson]

Actually nothing. I just wasn't sure what Lua would inherit from darktable. I tried it with and without the line and it works the same either way. So, we can get rid of it.

[wpferguson]

Remove any spaces in start or end of strings, the layout must not be done in strings. I see for example "of " and some other cases.

The problem is the way we format output, i.e.dt.print(_("export ")..tostring(number).." / "..tostring(total)). We could either .dt.print(_("export") .. " " ..tostring(number).." / "..tostring(total))or dt.print(string.format(_("export %d/%d", number, total))

[TurboGit]

dt.print(string.format(_("export %d/%d", number, total))

Yes, seems close to what is done on darktable core.

[wpferguson]

Does this match what you translated?

[TurboGit]

Does this match what you translated?

Yes I recognize the few strings I have translated there. So it's working.

[wpferguson]

I think the next step should be to clean up what we have, before we start adding new things.

• remove bindtextdomain statements
• change gettext.dgettext to gettext.gettext
• change translatable statements with variables to string.format()

[wpferguson]

@TurboGit how do want to proceed on this? Do you want me to push what I have to your branch do you want to look at #455 and see if I've covered everything?

[TurboGit]

@wpferguson : I'll have a look at #455 and we will decide what to do next.

[wpferguson]

@TurboGit I think this is how we should proceed on this:

• I'll add bindtextdomain back into Prepare translatable strings #455 and merge it so we'll have better strings but it will still work.
• It's late in the cycle to potentially drop a new set of strings on the translators so I think we should aim for 5.0 and start early in the cycle so that the translators have time to translate.

[TurboGit]

@wpferguson : Agreed I keep pushing back on this because of other priorities, sorry for that. So yes we should aim at 5.0 now and start working on this just after 4.8 is out.

• I'll add bindtextdomain back into ...

You mean that even if bindtestdomain is added we still have a proper translation for known strings in a different domain?

[wpferguson]

If I put bindtextdomain back, then the current translations we have will still work, minus the strings I changed.

When we start 4.9, I'll bump the API then remove the bindtextdomain again and merge that into the development branch. Anyone using master will get the development branch to develop and test against.

[wpferguson]

@TurboGit are we ready to start on this again?

[TurboGit]

I'm not ready as in vacation :) I'm trying to merge some (easy) PR but this require some time. What I can say is that I want this to be moved forward, so please review current status and let me know what would be the path forward. But again, yes I'm very motivated to see this project integrated in 5.0.

[wpferguson]

as in vacation :)

I hope you have a great time!

I'm very motivated to see this project integrated in 5.0

I am too. Once this is done I think we can bundle the lua-scripts as part of the build, which removes the git barrier. I'll give the ones that want to download an override so they still can and stay up to date.

And I have some other goodies for when you get back 🤣

[wpferguson]

@TurboGit when we stopped I think we were close, but we were too close to release to drop the additional strings on the translators. This is how I think we should resume:

• I'll pull all the translatable strings and give them another going over
• When you're ready, add the scripts back as a submodule
• After that I'll remove the bindtextdomain block again
• Generate the PO files with the scripts included

That should be all

[TurboGit]

@TurboGit when we stopped I think we were close, but we were too close to release to drop the additional strings on the translators. This is how I think we should resume:

* I'll pull all the translatable strings and give them another going over

Sounds like a plan to me. When you've done this first item, let me know and I'll add the submodule. As you know I'm in vacation, but if I have some time I'll update the sub-module ASAP and then I'll let you do the 3rd point above.

I'll add as a 4th point (before generating the PO) a review of the strings/documentation of the Lua scripts to ensure that all is clean before launching the translation. As there is a huge number of new strings we don't want to push too much work on translators :)

[wpferguson]

@TurboGit I've gone over the strings again and did some more cleaning and some refactoring. I think we're ready to move forward.

[TurboGit]

@TurboGit I've gone over the strings again and did some more cleaning and some refactoring. I think we're ready to move forward.

Which means adding the sub-module, right?

[wpferguson]

Which means adding the sub-module, right?

Yes

[TurboGit]

@wpferguson : We should close this at this stage I think.

[wpferguson]

I looked at it last week and had the same thought 😄

Done