RT Translation Process Update

Don’t assume anything… :wink:

I haven’t been able to find these entries in the gui (after using any tool/slider):

HISTORY_MSG_581;Local - deNoise lum f 1
HISTORY_MSG_582;Local - deNoise lum c

Those are just a couple entries. There may be more.

By the way, this is a perfect example of what you face when translating RT: if you don’t have full control and knowledge about all the tools, then you most probably won’t know what this means (what have you done in that history step).

That means you first have to know where the entry is located or how it is triggered, so you know what does it refer to. Then, you can translate it.

Oh, and if by any means those are not orphaned or obsolete, would you please post a screen capture showing where or how are they triggered?

Ding ding ding - we have a winner!

adodd@andyslaptop:~/gitrepos/RawTherapee$ grep -r HISTORY_MSG_581
rtdata/languages/Japanese:HISTORY_MSG_581;ローカル - ノイズ除去 輝度 細かい1
rtdata/languages/Chinese (Simplified):!HISTORY_MSG_581;Local - deNoise lum f 1
rtdata/languages/default:HISTORY_MSG_581;Local - deNoise lum f 1
adodd@andyslaptop:~/gitrepos/RawTherapee$ grep -r HISTORY_MSG_582
rtdata/languages/Japanese:HISTORY_MSG_582;ローカル - ノイズ除去 輝度 祖い
rtdata/languages/Chinese (Simplified):!HISTORY_MSG_582;Local - deNoise lum c
rtdata/languages/default:HISTORY_MSG_582;Local - deNoise lum c
adodd@andyslaptop:~/gitrepos/RawTherapee$ 

A good proof of concept for such a script - my rough plan was to, for each entry in default, grep everywhere but rtdata/languages for the reference, and flag anything that got no hits. I now have a known test case.

A little bit of Googling to find bash - Recursive Grep to show only total matchin count - Stack Overflow

adodd@andyslaptop:~/gitrepos/RawTherapee$ grep -ro --exclude-dir=languages CURVEEDITOR_CURVES | wc -l
1
adodd@andyslaptop:~/gitrepos/RawTherapee$ grep -ro --exclude-dir=languages HISTORY_MSG_581 | wc -l
0
adodd@andyslaptop:~/gitrepos/RawTherapee$ 

Will work on wrapping something to traverse the whole file later this week. I’m exhausted tonight and heading to bed REALLY early.

2 Likes

I have been translating GUI into Japanese and never felt that I waisted my time.

I check the language page more often than before (especially, I see a notice about a new tool) whether the default is updated. Once a certain number of strings (addition, deletions and amendments) is accumulated I post the updated GUI in Beep 5681.

Last of all, in this posting occasion, I want to mention my appreciation to the developments member of RawTherapee for the work and careful thoughts.

4 Likes

Numbered history messages are special because their keys are generated.

You will need to search with the corresponding ProcEventCode.

1 Like

@XavAL is correct in describing the way to find a entry you cannot find in the GUI. You need to shut down RT, restart with the new translation, search the entry… as he described. It indeed takes a lot of time. I am there since about two years and still working on it.

Yes, the answer sounds different. In my case, i think, the time wasn’t wasted, because i learned a lot of RT and i still do.

2 Likes

Over the night I was wondering if something like this might be the case - numbers like 581 and 582 are, um, unusual outside of the context of something like that. Looks like I’ll have to find the events table, parse it, and look for gaps.

Edit: Found the table, procevents.h

But at least that hints at where @XavAL might find these, from the looks of it, it would be in the history box, and judging from the text, some of the new local adjustments operations. Looks like a luminance denoise, not sure what f 1 and c are.

rtengine/procevents.h

Edit: You’ve been faster :wink:

1 Like

Btw: The table in rtengine/refreshmap.cc has to be synchron with the table in procevents.h regarding obsolete entries:-(

1 Like

Look at the wonderful can of worms we’ve opened here! :slight_smile:

Finding some way to automate the analysis is definitely going to be useful. Obviously the scope of that has increased significantly and requires more thinking.

Seeing “AUTOEXP” for all of the local stuff kinda seems strange to me - maybe all of the local adjustments stuff should have had its own category???

It’s just a wrong naming imho. Not so easy to remap this…

Yeah, maybe a long term project to start cleaning some of that up post-5.9 in the name of longer-term maintainability.

By the way, thank you to the translators from providing some perspective on this task.

How about, to leave the default file as it is at this point? RT is working fine in the latest dev-version.

Does it really matter, if there are orphaned entries? Missing entries we will find during the translation process.

1 Like

@XavAL definitely seems to think it’s problematic - although so far what seemed to be an orphaned entry was not actually orphaned. I think it is worth at least ATTEMPTING to do an orphaned-entry search both for now and the future, at least a partial semi-automated solution.

I can easily find strings outside of HISTORY_MSG_NNN that are orphaned in the source code
I should be able to find HISTORY_MSG_NNN orphans without too much trouble

Limitations will be:
If it exists in source but is commented out, I won’t flag it with any currently planned approaches. Most likely the good reviewing @heckflosse and @floessie have been doing will prevent most if not all occurrences of this from happening
If it exists in source, but is in a code path that is somehow dead/inaccessible, an automated tool won’t detect this. Again, hopefully mostly if not entirely prevented by our code reviewers.

To be fair, I think my explanation make you miss my point: I’m not worried at all about duplicated, orphaned or obsolete entries. I know how to deal with them. The point is that translators also work hard in RT, and their (our) work is not something done in a few minutes, whenever we are bored and don’t know what else to do.

By the way, the brand new Spanish translation was ready a few months ago, with the invaluable help of @paco.lores . We are just waiting a final (?) English version to re-check our translations.

1 Like

And thus I think it’s a responsibility to try and reduce your effort required if possible.

Longterm that might be something like crowdin or weblate (weblate seems to be 100% FOSS and there’s already an instance hosted on the pixls infrastructure, so while my past familiarity is with crowdin, weblate may be a better longterm option, although translator input would be beneficial here on the future roadmap too!)

Short term, if I can parse those tables and find obvious orphans with a few hours of work, it seems like I should.

Dupes are going to be harder, obsolete entries that are still somehow present in the source code will be too. But obvious orphans seems to be low-hanging fruit to me.

Edit: Side note, timing is slightly bad this week due to the upcoming Easter holiday.

1 Like

OK, gotta go do other stuff for a while, and will probably be returning to this on another computer.

#!/usr/bin/env python3

import clang.cindex
import subprocess

index = clang.cindex.Index.create()
procevents = index.parse('rtengine/procevents.h',args=['-x', 'c++'])

for chld in procevents.cursor.get_children():
    if(chld.displayname == 'rtengine'):
        for c in chld.get_children():
            if(c.displayname == 'ProcEventCode'):
                for pec in c.get_children():
                    #print(pec.kind, pec.displayname)
                    grp = subprocess.Popen(('grep', '-ro', '--exclude=procevents.h', pec.displayname), stdout=subprocess.PIPE)
                    wcr = subprocess.check_output(('wc', '-l'), stdin=grp.stdout)
                    grp.wait()
                    print(pec.displayname,int(wcr))

Should we have a separate thread for translation prep work and coordination?

I do have a possible finding:

EvSHHighQuality 0

Edit: This appears to have been an orphan since sometime between 5.4 and 5.5, it was used in 5.4:

rtgui/shadowshighlights.cc:            listener->panelChanged (EvSHHighQuality, M("GENERAL_ENABLED"));
rtgui/shadowshighlights.cc:            listener->panelChanged (EvSHHighQuality, M("GENERAL_DISABLED"));

It might be useful to translators to use something like Andy’s script on different commit levels and run the outputs through diff to see what has changes since they last checked.

I am doing this with a calculation chart. Just paste the new version and it immediately shows me, where the differences to the former versions are…

1 Like

It turns out buried in tools, there’s already a script that does some of what I was intending to do - see @Thanatomanic 's comment on Removal of obsolete strings · Issue #6457 · Beep6581/RawTherapee · GitHub - but traversing the history events table to find its orphans is new, so after poking at the legacy script, I’ll likely be de-scoping mine to focus on events table maintenance.

@Thanatomanic also pointed out generateTranslationDiffs which I was already aware of - that appears to/should handle the task of flagging new untranslated strings for translators. The main issue is that it is dependent on default being in good shape, and reviewing that was one of the final tasks that M was going to do.

We already found a confirmed bug due to some cruft in default that should not be there.

1 Like

Just an idea: translation related work-discussion could be on its own thread (and deserves to be) for visibility and ease of search.