Closed andyholmes closed 11 months ago
Please count me in as well.
I've dealt with translations on Crowdin before, but I really dislike the translation interface and the way translation fixes aren't deal with because they are easily overlooked. So I gave up on Crowdin and would rather translate the old-fashioned way or prefer an alternative site like Weblate or Transifex.
Having skimmed it very briefly, the interface does seem... surprisingly clunky. However, the global translation suggestions are a nice feature (and seem like they have the potential to do some percentage of the translating for us, basically — how large a percentage, I have no idea), and the screenshot-based context feature is a neat idea.
Since some of you seem to be quite confused about Crowdin, let me do a quick comparison between it's and PoEdit's best features. Main thing to highlight is in bold, meaning GSConnect can stop accepting git PRs and PoEdit users can still use the tool they like.
Crowdin:
PoEdit:
translation fixes aren't deal with because they are easily overlooked
Counter-arguments:
and seem like they have the potential to do some percentage of the translating for us, basically — how large a percentage, I have no idea
It is similar to PoEdit - even though there are more variations of suggestions, they must always be selected individually by a translator. There is even a search filter for reviewing translations done by it, to prevent machine translation abuse.
@Madis0 I'm not against working in teams or discussing or anything, like I said, I do a lot of translation work on Transifex and Weblate also so I know exactly how all of this works. No need to explain it to me. I just don't like Crowdin, I have bad experiences with it, so I'd rather not use it. Do you understand that?
and the screenshot-based context feature is a neat idea.
Weblate has that as well, so it's neat, but not unique.
My two bits: Crowdin uses ICU locales and locale definitions. GSConnect is based on Gnome libraries, thus uses locales and locale definitions as defined in glibc. And they do differ. And it does cause problems (translating free software for about a decade). Interface might deceivingly be easier for beginners, though I'd rather take a good translation over an easy one anytime, as I'm sure all end users do. Therefore, I'd appreciate if translating the way it was done so far still remains an option. Thank you.
Possible to add French ? I would be happy to do all french translations ;) my account is vincen on crowdin if needed....
Hi everyone, I thought I'd let you know v20 is getting ready to be released in the next few days maybe, although I'm in no rush. For those not using crowdin, there have been a few string changes since last release, but nothing too big.
As usual let me know if you need some time to get around to it and I'll be happy to wait until you're ready.
@andyholmes I would love to help out with a Hungarian translation using Crowdin.
@zalanlevai Hungarian translation is almost complete, I'm just working on the latest update.
@andyholmes Hey, I'd love to help out with Lithuanian translation. Please add Lithuanian language to Crowdin.
@andyholmes Hi, could you add Danish to crowdin? I would like to translate it :smile:
@LethalEthan all added, should be good to go :)
I wanna add a Serbian translation if you don't mind :D
@andyholmes I would like to add Chinese translation to GSConnect, could u please add Simplified Chinese (中文简体) to crowdin?
Sorry guys, my memory is terrible and I forgot to cross-post my comment from the release notes.
There were quite a few string changes and additions in v25/26, but I got caught off guard by a protocol change in KDE Connect and had to push out a release before I could review them or update the translation template.
I hope to do this either today or tomorrow and I'll mention this issue in the commit, so hopefully you get pinged if you're not on crowdin.
Sorry for the delay for everyone, apparent xgettext
has a major regression parsing template literals in JavaScript with the 0.20.1 update, which ironically claimed:
"JavaScript: xgettext now parses template literals correctly"
I was up late last night trying to get the template file updated, but I'm going to have to figure something else out; either build an older version of gettext from source or remove all template literals from translatable files.
@andyholmes I would like to translate it to Traditional Chinese, how to add a language in crowdin?
@laichiaheng I've just added Chinese Traditional to the Crowdin project.
Crowdin also offers three additional options:
Let me know if you'd like any of those enabled in addition to / instead of "Chinese Traditional".
I've also added a translation file to the repo, and merged all outstanding translation PRs. As soon as I've double-checked to be sure I'm not screwing anything up, I'm also going to update the translation master, because it looks like there have been a number of string changes since the last update.zh_TW.po
(Correction: a zh-TW.po
file. That's the name Crowdin gave it, who am I to argue?)
@ferdnyc thanks for updating the POT file, I was fighting with xgettext until 3AM last night. Just to be sure, are you running gettext <= 0.19.8.1
(you should unless you're on Fedora31/Ubuntu 19.10/etc)? See my last note on bug 50920.
@andyholmes Yeah, I saw that. Still safe here:
$ gettext --version
gettext (GNU gettext-runtime) 0.19.8.1
Copyright (C) 1995-1997, 2000-2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Ulrich Drepper.
@andyholmes I do have a question about the translation file names. As you can see from my (edited) comment above, Crowdin sent through the Chinese Traditional translations as zh-TW.po
instead of zh_TW.po
, so I went with it and adopted the zh-TW
name for the files, in LINGUAS
, etc..
I see in deaeeed0 you renamed the ar-SA.po
file to ar.po
(went the other way on that, in other words), but looking at #638 new translations still seem to be coming in from Crowdin as ar-SA.po
. (So, now both ar.po
and ar-SA.po
exist, and are out of sync because when I rebuilt the translations only ar.po
was updated.)
How should we handle that?
(Edit: Same deal with ca.po
and ca-ES.po
. Edit2: Though, now that I look at it that one's even weirder, because ca-ES.po
exists but it's really out of date; Crowdin seems to have adopted the ca.po
name, for those updates.)
@ferdnyc As far as I've been been told, in general the two letter form is preferred (eg. fr
which will work for France and Quebec) unless it's actually significantly different such as pt
and pt_BR
(Portugal Portuguese and Brazilian Portuguese) or someone wants do both such as our Netherlands/Netherlands Netherlands/Belgian...Dutch (?) translator.
I'm more confused now that I try to think about it, but I think gettext translations are separated with an underscore (_
) while Crowdin requires a hyphen (-
) (except some languages like Serbian that have Latin and Cyrllic forms and need an @latin
), which is why we have the mappings in crowdin.yml
. Then the WebExtension has its own form, which is why I wrote a script so I didn't have to remember :confused:
I don't know, usually @piotrdrag tells me when I get mixed up :sob:
Aha!! crowdin.yml
was the piece I'd missed.
I think gettext translations are separated with an underscore (
_
)
I wonder if it actually cares? I'd added zh-TW
to po/LINGUAS
, not noticing that there was a way to remap Crowdin's names, and AFAICT gettext seems to be fine with using and updating zh-TW.po
.
What does seem to care is GlibC. As a test I tried to open Totem with LANG=en-GB
(after LANG=en_GB totem
opened fine; I don't have a lot of supported languages installed on my system), and I got this:
$ LANG=en-GB totem
(totem:7839): Gtk-WARNING **: 02:17:58.649: Locale not supported by C library.
Using the fallback 'C' locale.
(totem:7839): Clutter-WARNING **: 02:17:58.698: Locale not supported by C library.
Using the fallback 'C' locale.
(Which is a bummer, because Qt applications open the same translations whether the language name is specified as lang_locale
or lang-locale
.)
So, I guess I'll go rename that file now, and add a mapping in crowdin.yml
. :roll_eyes:
Problem is (and I mentioned it before) that Crowding bases their locales and locale definitions on ICU (libicu), while Gnome and everything that depends on gnome libs uses locales and locale definitions as defined in GNU C library (glibc). Which makes the choice to use Crowdin a very questionable one. You simply can't use ddifferent locale definitions other than those that the core library on which the program is based is coded. On top of it, Gnome provides no "user friendly" way of switching translations for a single program. Locale needs to be set for the entire session, and if gsconnect translation is not using the proper locale code which Gnome session expects, it will not be used.
I still strongly suggest to everyone to create/upate translations via git and submit merge requests. Sure, Poedit and similar localization programs may not have as idiot proof interface as what Crowdin offers, but it is the only way to guarantee that submitted translation files will be working and used as expected.
P.S. Chinese locales as per glibc are:
zh_TW is the correct one in your case.
Which makes the choice to use Crowdin a very questionable one. You simply can't use ddifferent locale definitions other than those that the core library on which the program is based is coded.
*shrug* That strikes me as overly alarmist.
I mean, Crowdin is built by the poedit
developers, and they're fully integrated with each other. Heck, there's a "What is Crowdin?" link on the poedit
welcome screen, if you launch it without loading a translation file. Once you authenticate you can even use it to retrieve and update translation files directly from Crowdin. Far from being in competition with / alternatives to each other, they seem very much designed to work in concert. It needn't be an either/or.
Plus, gettext
doesn't really have any concept of locale — as I noted, it was perfectly happy to update zh-TW.po
when the file was named that (and generate a locale/zh-TW/LC_MESSAGES/org.gnome.Shell.Extensions.GSConnect.mo
file from it) — it'll use whatever names are defined in the LINGUAS
file it works from. I think you're giving poedit
/gettext
too much credit for managing the translation locales more intelligently, when there's no evidence I can see that that's actually the case.
Even when translations are prepared in Crowdin, they're submitted via git PRs, so it's not like we've ceded control of the translations or anything. Believe me, I could make a mess of this stuff just as easily without Crowdin as I can with it, I don't need its help to screw up. :wink:
Why do I keep getting notifcations for the chinese translation? 🙈 I barely understand english!
😂
@ferdnyc It is not alarmist, it simply is the way it is. Crowdin does not let you select all locales that Glibc (and thus Gnome) uses. Them being Poedit developers means nothing, Poedit works with whatever you tell it to work with. On the other hand, Gsconnect expect Glibc locale codes. Again,it is not alarmist, it is simply a matter of a fact.
As another note, Weblate and Transifex are two web based transltion platforms similar to Crowdin, and both of them have no problem to recognize glibc locales.
gettext indeed doesn’t care what language codes you feed it, but GNOME expects glibc locales and won’t work with anything else. So installing ar-SA.mo
is pointless (and even ar_SA.mo
won’t work for any ar_ locale other than the Saudi Arabian, as far as I know). As I see it, it doesn’t matter what codes Crowdin uses as long as the result is .mo files recognized by glibc-based systems.
By the way, this being a GNOME Shell extension, it might be a good idea to peek at what the shell does wrt. language codes when adding new languages: https://gitlab.gnome.org/GNOME/gnome-shell/tree/master/po
gettext indeed doesn’t care what language codes you feed it, but GNOME expects glibc locales and won’t work with anything else. So installing ar-SA.mo is pointless (and even arSA.mo won’t work for any ar locale other than the Saudi Arabian, as far as I know)
Yes, I fiddled with crowdin for a bit, but gave up because the Arabic translator hasn't actually submitted any strings yet. For some reason the ar-SA: ar
mapping is the only one which is not working correctly. If it's not doing harm we could leave it or just remove it and wait for them to appear again.
By the way, this being a GNOME Shell extension, it might be a good idea to peek at what the shell does wrt. language codes
:+1: Also a good idea, thanks :)
EDIT: got it :) EDIT2: @ferdnyc sorry about the barrage of Travis CI emails, ignore those it's because I deleted the branch before the ESLint job completed
@andyholmes I'm deeply sorry. Could you update the translations again? I have corrected lots of wrong translations today, lots of them had been translated by Simplified Chinese users, so I had to find them and correct them to Traditional Chinese, some of them included two %s in one sentence, and I didn't know that the order of them must be the same, because the order of them in Chinese are reverse. I also have added new translations. By the way, some of them had been translated, but they were still in English.
@laichiaheng no problem, all merged :) Let me know if the translations still aren't working after a rebuild.
@ferdnyc Do you still have gettext-0.19.1
? If so, would you mind regenerating the POT file?
@andyholmes Whoops, just saw this sorry. I do still have 0.19.8.1 (which I assume you meant), I'll take care of it now if it's not already updated.
Done, and the Crowdin PR is resyncing now.
@andyholmes Would it be possible to add Brazilian Portuguese (pt-BR) ?
Translation done.
Hi translators,
For the first time in awhile there are some new strings. We now have AppStream metadata that distributions who package GSConnect may choose to include.
More importantly, some initial work has begun to annotate GUI elements for accessibility (eg. screen readers for visually impaired). Some of these may not be commented yet, but do your best :)
So we're gonna get some new cool stuff. 😎
Thanks!
Codename for v40 is "boring" :wink:. It's going to be a release of bug fixes, performance improvements, memory reduction and code refactors.
Next release, well that might be big. :slightly_smiling_face:
Hello, i have added the frisian translation to crowdin, I hope it can be included in an upcoming version of gsconnect :) thank you for your work.
Is this still used by translators? If yes, can an admin pin this (or someone ref it in the README) ? If not this should be closed.
This is a thread for discussion of translations and notification of changes to translatable string. If you are a translator, please subscribe to this issue to be notified of changes.