Yeah. I think the main issue is the lack of a transition plan - at least in my case, I would not want to see a formal fork if it can be avoided. However the lack of communication from @Morgan_Hardwood is problematic in this regard - I think there are enough people like @Thanatomanic and @heckflosse who could take over the release process for one release, but ideally they get permission to do so (even if temporarily) from the project’s owner.
One of the sticking issues appears to be a review of the default language as @Morgan_Hardwood says he’s concerned about wasting translator’s time on obsolete strings - Roadmap for v5.9 · Issue #5632 · Beep6581/RawTherapee · GitHub - now the question is:
How many obsolete strings might there actually be? Perhaps if some obsolete strings are missed, the amount of time spent by translators might be negligible?
Perhaps this is an opportunity for automation? What’s the review/revise process that @Morgan_Hardwood has in mind? Could this be something where a tool is run on the code to determine which strings no longer have anything referencing them and thus can be garbage collected?
Perhaps another improvement opportunity would be to use something like crowdin? https://crowdin.com/ - I’ve been involved with other projects that used it seemingly successfully. I could try contacting Ethan and Max from Omni - OmniROM dashboard in Crowdin - for tips on integrating it.
We need to set priorities. Having an updated language file for all our supported translations is certainly not one on my list… It should also be much easier to create a minor release 5.9.1 with only updated translations and maybe some critical bugfixes.
I think this is not necessary at the moment: quite some active members on this forum have been using the latest dev builds for some time now. Some reports have been filed, but no critical bugs have been found. I would be willing to put 5.9 out there as a culmination of a rough two years, accept that it will not be perfect yet, but then work towards a stable future.
It was my assumption that if there was any aspect of moving forward without Beep6581, it would be that he definitely had this concern and might be unhappy if others didn’t at least take it into consideration.
I do agree with you that I think the concern of wasting translator’s time is probably overblown - I question how many obsolete strings that are now orphaned weren’t in RT as of the 5.8 release and thus were likely already translated. There might be some strings that were added and then removed with a subsequent patch in the interim, but how many examples of that are there? Likely only a small handful and a drop in the bucket as far as translator time.
That appears to look for untranslated strings that are in default but not the other languages. The concern that was raised appeared to be that there might be strings in default which are orphaned - and I don’t think there’s anything to do that.
As I mentioned in my post, the fact that Windows builds are being done in CI as opposed to manually likely mitigates this issue. I can’t remember, are MacOS builds automated?
Youre right, when i started the localisation for LA, he asked me to wait, until the default file will be revised.
For my own i continued the translation (not yet fully finished) and i didnt find a lot obsolete strings. For the few i found and for the missing ones, i opened a issue in github and they were removed. By the way, i wouldnt say, the time was wasted
i fully agree to the concern of pp3 compatiblity, sometimes i find my pics more reddish or colourful than before, thought, its a lack of my knowledge to RT, but never thought it could be a problem of compatibility. Every time this happens, the haze removal tool shows a saturation of 100%
Great to hear inputs from one of the translators on this issue, since moving forward without that review of default is most likely to impact you.
Also:
Edit: Odd. Ideally that shouldn’t happen, although I do remember seeing at least one report of a behavioral change from before/after color profile information for an unsupported or partially supported camera was added. I wonder if, when a color profile is missing, but the UI setting indicates that one should be used if available, instead of the setting being automatically changed to something appropriate (such as “no profile”), it stays with the default and behavior changes once the fallback behavior is no longer necessary. I wonder if this is the case for you - what camera, and what were your before/after versions that were affected?
Thats the trick. Since i was sure, its my very poor knowledge of RT i didnt take care of the RT-Version i used but i am very sure, at that point i did not have any idea of camera profiles and didnt use them. Btw, i am using a Sony Alpha77 M II and the Sigma lenses 18-200 are not correctly recognised.
As a translator myself, I don’t think the problem of orphaned strings should be diminissed. I have also found what appear to be duplicated entries, one obsolete and another one actually used in the gui (don’t ask for examples, I can’t remember which ones; there are almost 4k entries).
Think of it such as this:
you’re translating RT, but your mother tongue is obviously not English
you find some random string that you can’t locate in the gui (that doesn’t mean it’s not used, because sometimes those strings are shown in the weirdest places). So you take your time trying to figure out where the h**k it is, and what is it that it means
as suggested, if you finally can’t find it anywhere in RT gui, you open an issue and wait for an answer
when you get an answer, you can continue your efforts with the translation
That’s not a couple minutes of translator time, believe me.
I know the amount of time a translator spends is much less than that spent by a developer, but you can’t expect a translator to be constantly checking which changes appear in the gui, so most probably it will only be checked 1-2 times a year. And that presumably means quite a few changes that have to be identified, understood and translated.
Do whatever you think is best for the project, but please, don’t think translating RT is a piece of cake… Just consider the enormous time spent translating all the strings inside LA, which happened in just one year. And they where edited quite a few times… (again, nothing close to the time spent coding it, but even so).
OK, you’ve got a very different answer from one of the other translators. That’s very valuable input - and sounds like you’ve actually found scenarios of obsolete strings. Based on this I’ll definitely look into writing a tool to try and find such scenarios.
I’m assuming the obsolete string in question is now gone, but by any chance do you remember roughly when you found it, what it was, and when it was nuked? Sounds like a good test case for such a tool.
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?
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.
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.
@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.
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.
