POC: translation done by darktable.

TurboGit commented 5 months ago

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 #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 commented 5 months ago

@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 commented 5 months ago

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 commented 5 months ago

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

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

wpferguson commented 5 months ago

Does this match what you translated?

script_manager script_manager2 copypaste

TurboGit commented 5 months ago

Does this match what you translated?

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

wpferguson commented 5 months ago

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 commented 2 months ago

@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 commented 2 months ago

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

wpferguson commented 1 month ago

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

I'll add bindtextdomain back into #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 commented 1 month ago

@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 commented 1 month ago

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.

darktable-org / lua-scripts