Update of .ts files

[pafri]

Localization "automatic" update

The .ts files aren´t currently updated much often. Could that issue with UI being up-to-date be solved; or at least the update made (now and from time to time, but more frequently) for those already for 4 months not updated localization files?

[Simran-B]

Not sure what you are asking for. If you want to contribute UI translations then you need to update the .ts files as part of that process (see https://github.com/olive-editor/olive/wiki/Translations). Doing just the update every so often would be rather pointless, as untranslated strings will show the original English text, which should also be the case if the .ts files are outdated.

[itsmattkc]

Updating the translations is the responsibility of the translator. Either use lupdate or run CMake with -DUPDATE_TS=ON (as per https://github.com/olive-editor/olive/blob/master/CMakeLists.txt#L21) and the TS files will be updated ready for translating.

EDIT: Rewritten for accuracy. This used to only mention CMake and that it had superseded lupdate, but both methods are acceptable.

[Simran-B]

Good point about -DUPDATE_TS=ON, although it doesn't feel like it's superseding lupdate. It requires you to have CMake, which you are probably unfamiliar with as a translator. It will also update all .ts files, not just the one you are typically interested in. lupdate can still be used to make it easier, can't it?

[itsmattkc]

Yes, lupdate is also usable as documented in the wiki. As you say, there's no real point to doing it on our end since either way the lines will be untranslated in-app, hence why we leave it up to the translators.

[pafri]

Not sure what you are asking for. If you want to contribute UI translations then you need to update the .ts files as part of that process (see https://github.com/olive-editor/olive/wiki/Translations). Doing just the update every so often would be rather pointless, as untranslated strings will show the original English text, which should also be the case if the .ts files are outdated.

This is the very normal method in development, that the developers make such kind of work. Maybe your experience tells you otherwise, but I feel the suggested method, that poses the emphasis on translator's participation (mostly above the common skills of usual translators - volunteers, as exception among the open source projects. The reality is: many projects don't have translations/translator. All the strings aren't up to date - there are less or more untranslated strings, and that's the function of localization files. In the situation of missing translations of strings, the original comes simply onto the scene - and GUI always includes the texts, which is the communication mean: application - user.

[elsandosgrande]

@pafri I can't really make out what you're trying to say either :sweat_smile:. Could you explain it in the simplest way possible?

[pafri]

When Olive doesn't use something like translation server (Transifex, Weblate etc.) the way, how to keep the translators doings their job on more regular basis and indicate the interest in making the process as easy as it could be for them, is from time to time update the .ts files. Once a week, or two weeks, or at least monthly, but show some effort in this field of "project's life cycle". It could/should encourage them to make more, more often.

[pafri]

It's about expectations. For me, I wouldn't search for any manual, how to update the .ts file - and it's nice, that there is such manual included in Olive project (I've already updated the .ts file using it). First: if there would be .pro file, I would probably know how to do it anyway - after previous experience with such solution - but used more frequently many many years ago; the pattern for command line: lupdate something.pro or so, but basically I would expect the job is already and reasonably done.

[elsandosgrande]

@pafri Incremental updating of translations? As far as I've seen, that already happens, but I see Simran's point as well. Regardless, the .pro file is no more because we have fully deprecated qmake and now exclusively use CMake.

Are you saying that it should be as easy to make translations (test, compile, …) as with .pro files, but without them, or am I misunderstanding something again? If that is what you're asking about, I'm not sure if there is a way to make that happen, but I don't know my way around Qt all that well, so I might be mistaken.

[pafri]

No, I don't care how it happens - if I know how to do it. The point of the post was, and the answers show that there is no force/power or time for this, that the files should be updated more often than once every six months when I overdo it. More than 150 new or fuzzy strings in that file are a major reason for doing so (yesterday was late, as they say). A cursory glance at the files shows that they have not been developed by either the developer or any translator for at least four months. And why, I ask myself. The answer: "because translators are lazy" does not look (for the public) convincing.

[Simran-B]

To bring it to the point: translations aren't a priority and are fully up to the community. This is unlikely to change. It's a nice-to-have feature. Olive has a long way to go to get the must-haves right, with extremely limited resources, I should add. It is in an early alpha stage and still undergoing massive changes, potentially invalidating many translation strings over the coming months. We even discouraged translation contributions for a while to not waste people's time. If you still want to put effort into translating Olive, then you can do so, and I don't think that it's too much to ask translators to run lupdate occasionally in that case. Edits are expected to be made with Qt Linguist, and if you have that, you also have lupdate. When a stable 0.2.0 is near, we can officially update the files and do a callout to translators on Discord. Once the project is more mature, we can add a GitHub Actions workflow to update .ts files automatically, but this is not the time.