Closed Olf0 closed 1 year ago
@spodermenpls, as the German translation was also finished, before I did the two minor source string rectifications described in the initial message, I performed the trivial adaption of these four German strings at Transifex. Still there are many strings not yet reviewed, but this is purely optional: A language becoming 100% translated is sufficient for triggering the Transifex integration to commit to GitHub (the way I configured it). As the German localisation likely is the most used one, I would appreciate if you take a look at the unreviewed strings and either mark them as reviewed or alter them, provided that you can spare the time (because this is only quality assurance).
Thanks for notification! The Ru locale was updated.
However, in an ideal world there should be a separate infrastructure to update UI translations independently of the packages themselves. There are three reasons.
Translators should check the result of their work before releasing it to the public, but many cannot test it because they cannot build latest packages on their own (for the lack of special skills and tools). It means that rpms come out with beta-quality translations and in case of translation errors the users have to wait until the main coder decides to trelease a new version of his rpm. It might mean that the corrected translation immediately becomes outdated and the new strings are -beta again.
Volunteer translators may not be always available on time to update their strings before a new code release.
Some coders abandon their packages (but the apps remain useful). Translators, who make new localisation files, cannot distribute them as part of the corresponding package.
A possible solution might be a separate repository for qm/mo files and an app or function in Chum to look for any translation updates and install/overwrite old translation files independently of rpms and without updating the actual packages (binaries and data). E.g app-version X, translation version X.Y (where Y is version of translation for the app package ver.X).
@dikonov, WRT
However, in an ideal world there should be a separate infrastructure to update UI translations independently of the packages themselves.
Technically this is well feasible by the integration of an external translation repository (preferably also at GitHub) via a git submodule. But mind that the translations are already decoupled to some extent by the use of the ID-based string l10n scheme Qt provides, plus the (optional, but recommended) external management of the translations by Atlassian's Transifex. I personally do not believe that externalising the translations to a separate git repository and importing it as a git submodule is worth the effort for a small application like this. I also believe that it is fine to handle the l10n aspect as any other aspect of a software: It may have bugs, it does have interdependencies with other components and contributions usually are not synchronised; thus at times mishaps occur, but it is just software, it can be altered and fixed at any time.
But if you are convinced that it is worth the effort and does not complicate the workflows (I am a bit afraid that it does, but sure willing to practically try this in order to obtain a well founded opinion): PRs are always welcome. Note that I am not the only one who has to be convinced, we are three maintainers, so it might take two to approve a significant structural change like this.
the translations are already decoupled to some extent by the use of the ID-based string l10n scheme
This is completely true. The problem lies in timely distribution of the new translations from translators to the users.
Translation processes of ALL apps (when run by volunteers) are NOT time-synced with code development. Coders and translators are different people living their lives independently. When a new version of translation (for almost any small app) is done, the translator can easily put it to his device and use it personally (with a previous released version of an app, that is always 1 step behind the coder's pre-release version). However, delivering the translation to all users in time, while it is still valid, requires infrastructure. And the infrustructure (chum, openrepos, store) treats translations as inseparable parts of packages and holds them in limbo until a new package gets released. Hence problems 1, 2 ,3 arise.
@atlochowski (for pl
) and @pherjung / @phklrz (for fr
): If you need more time, please let me know. I do not mind postponing the next release by a few days or a week, but not more than that. I might use the time to achieve consensus on adding PR #181, hence for a proper planning, I would like to know if another week is helpful for you to finalise the fr
and pl
translations or if you currently lack any time for localisation work. Mind that it is absolutely O.K. to state, "no, its likely not feasible for me to finalise my translation before, e.g. (latest suitable date), Sunday evening, 2. April 2023". Much better than to stay mum, because that does not allow for any proper planning.
@Olf0 I'm on holidays so don't wait for me.
I'll finish the translation this Sunday. @Olf0 If I don't get in time, I'll leave a comment here.
My laptop is in repair and I don't know when I get it back, so I won't be able to finish translation.
I'll finish the translation this Sunday. @Olf0 If I don't get in time, I'll leave a comment here.
I need some more time to review some translations. I have some time Thursday.
I need some more time to review some translations. I have some time Thursday.
That is sure O.K: Take your time.
I will try to use the time to create the documentation changes for PR #181, something I had hoped for to start with this weekend, but time was fleeting.
@pherjung, I coarsely looked over PR #183, and "Recuperation" for "Retrieval" was the first thing I noticed: Maybe a simpler term should be used in the source language (en
), though in IT-language "to retrieve" usually means simply "to fetch", "to pull", "to download" (i.e., the "re-" prefix lost its meaning of "back" or "again") and this is how it is meant here, i.e., something like "tirer".
But this a remark from somebody whose French is quite bad, hence that should not interrupt or distract you from reviewing your translated strings; it is just something I noticed, maybe incorrectly.
P.S.: As always for everybody in any localisation of any software: If you think a source string should be enhanced, because it appears to be wrong (used words, grammar or its meaning) or is difficult to understand, please open a PR or denote that in an issue report.
Tirer
is not the right word and récupérer
is really the good one, but I'm not translator at all. There is maybe a better alternative.
It would be nice to have someone else check my work, but I'm happy to have finished the translation \o/.
Many thanks to @carmenfdezb, @dikonov, @eson57, @jaimeMF, @martonmiklos, @okruhliak, @pherjung, @spodermenpls for translating, updating and / or reviewing the localisations of the SailfishOS:Chum GUI application for the locales de
, es
, fr
, hu
, ru
, sk
, sv
!
JFYI, v0.6.0 containing the overhauled localisations is available at GitHub and in the SailfishOS:Chum:Testing repository. I will submit v0.6.0 to the SailfishOS:Chum repository this night.
Thanks, I checked the Slovak translation, it looks fine to me. Good job, @Olf0! :+1:
In the French version there is a small typo error in the page About. A space is missing and I forgot to translate the word and.
In the French version there is a small typo error in the page About. A space is missing and I forgot to translate the word and.
Due to technical changes (and hopefully a bugfix coming in), I plan the next release for the 20. - 23. April.
I have found a French user who is willing to check the translation. He is waiting for the approval to integrate the transifex group.
I have found a French user who is willing to check the translation. He is waiting for the approval to integrate the transifex group.
Thank you and I accepted mips_tux's request at Transifex.
In the French version there is a small typo error in the page About. A space is missing and I forgot to translate the word and.
@pherjung, I would appreciate, you fix that. mips_tux (Pierre) does not seem to know about it, he changed something else.
Thanks @pherjung, just merged PR #187 "Translate 'translations/sailfishos-chum-gui.ts' in 'fr'" including your two fixes to the "About" text and the newly translated paragraph, which was overhauled in the source string.
Hence I may release sooner than originally planned. :smiley:
@Olf0 I have made an observation regarding one of the locale strings. There is the %1 %2 updated
one, with %1
acting as a placeholder for the package name and %2
as a placeholder for the package version. However, at least on my end (XA2), the notification pop-up banner only ever displays "updated" (or "aktualisiert" in German), never the package name or version that was actually updated (regardless of OS or app version, always been that way). I already did some research in this repo, but couldn't find a mention of it, is this is known shortcoming, or maybe something that I should open a separate issue for?
@spodermenpls, thank you very much for looking so closely at the translations in real life, otherwise this surely would still be unnoticed.
I already did some research in this repo, but couldn't find a mention of it, is this is known shortcoming, or maybe something that I should open a separate issue for?
I have never heard of any such issue, IIRC all issues so far were not translations related. Hence please file a new issue. Thanks!
You might include these references:
Have you tried if the Install and Remove operations are also affected (I would assume so)?
Dear translators,
thank you very much for joining the newly created SailfishOS:Chum GUI application translation team at Transifex. Now that I finished the technical aspects of the migration of the text strings (TS files) to Transifex and integration of Transifex into the Git workflow for the SailfishOS:Chum GUI application, I would appreciate much, if you overhaul the translation in the language you are assigned to.
As always, if a source string appears to be wrong, distorted or just strange, or something else seems to be wrong with the text strings (e.g., when looking at the SailfishOS:Chum GUI app), please open an issue here at GitHub.
Unfortunately I found 4 flaws of the source strings, when looking at them at Transifex (which makes detecting flaws much easier): There was one wrong ID ("string label") and four strings with spelling inconsistent to the one used for the READMEs at GitHub and OpenRepos (see commit 9ae1d87).
Hence the three finished translations (es, sk, sv) now show one completely new string (the one with the altered ID), which is just slightly altered, alike the other three strings shown as changed due to the spelling of "SailfishOS:Chum:Testing repository", because this is how the SailfishOS-OBS spells it and how I consistently spelled it elsewhere, recently. @carmenfdezb, @eson57, @jaimeMF, @okruhliak (holask@tx), it is just the same small change for these four strings and Transifex offers you translations suggestions at the right side of the translation web-page proper, of which the topmost is usually the prior translation (also for the "new" string) which can be easily copied with the miniature "two sheets of paper" symbol as a starting point.
The other translations (fr, hu, pl, ru) are a bit further out-of-sync with the current source strings, because they have not followed this year's source string changes. @atlochowski, @dikonov, @martonmiklos, @pherjung, @phklrz, now that the overhaul of the translation process has settled would be a good time to update these translations.
I am planning a new release of the SailfishOS:Chum GUI application the weekend after next week (i.e., on Saturday or Sunday, 2023-03-25/-26), which will be primarily about updating the translations, hence it would fit perfectly, if you update the translated strings at Transifex until then or notify me (e.g., here) if you need more time.
Thank you!