-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-07-30 01:08, Yamaban wrote:

For now the best way to help with translation is to work direct with upstream, so any translation done there will come down to us all with the next release.

Yes, that's true :-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlW5X9EACgkQtTMYHG2NR9XGyQCdHwUJdaoSxcc8arswtWAOSLEO WV4AnAk8HFwHresJb8RlHlcB0uNnd8bZ =R/RM -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 30.07.2015 um 09:34 schrieb Jay:

If you do their job it only removes the pressure off them to find smarter ways to do the translations or polish their processes. Or better cooperate with their "customers".

AFAIR, the "KDE Team"s "customers" are developers who want to build something on top of the KF libraries. The fact that a so-called "desktop environment" falls out of the project which is apparently somewhat usable is just a side effect, but not really intentional. And so nobody cares really about translations and stuff. But of course you can become active in upstream KDE and change that. If you want an environment geared towards end-users, I'd suggest using one that's designed for that task, e.g. GNOME or XFCE. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 30.07.2015 um 10:22 schrieb Jay:

Am Donnerstag, 30. Juli 2015, 09:52:42 schrieb Stefan Seyfried:

...

Am 30.07.2015 um 09:34 schrieb Jay:

...

If you do their job it only removes the pressure off them to find smarter ways to do the translations or polish their processes. Or better cooperate with their "customers".

AFAIR, the "KDE Team"s "customers" are developers who want to build something on top of the KF libraries.

I think they have different groups of "customers", not just developers. Also end-users and distro-builders like openSUSE.

...

The fact that a so-called "desktop environment" falls out of the project which is apparently somewhat usable is just a side effect, but not really intentional.

Isn't KDE the short-hand for "K Desktop Environment"? Never occurred to me the desktop is just a by-product.

First paragraph from kde.org:

"The KDE® Community is an international technology team dedicated to creating a free and user-friendly computing experience, offering an advanced graphical desktop,..."

By-product? Please...

There is no KDE in the Distribution. There are the KF5 libraries/frameworks, there is Plasma Desktop etc.pp. The sentence you are quoting is probably slightly outdated, AFAIU. It was quite some time ago (several years, probably around KDE4 time) a more or less disguised announcement that there is mainly interest in building a framework, that others can use to build things on. But I stopped caring about KDE loooong ago, so I am not up to date with the current state of affairs. But the user experience you are describing is closely matching what I remember from that Announcement :)

...

And so nobody cares really about translations and stuff. But of course you can become active in upstream KDE and change that.

If "nobody cares" - why should I?

Well, you obviously do or you would not be concerned with the current state.

...

If you want an environment geared towards end-users, I'd suggest using one that's designed for that task, e.g. GNOME or XFCE.

See quote above.

I can't find one that looks related. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-30 09:34, Jay wrote:

So openSUSE does the translations for KDE (and others)? You shouldn't do that. IMO it's their responsibility.

No, we don't. We try to translate some files (I don't know what they are, really) that contain application descriptions and that end generating the system menus. I think they come from many sources, and they come hugely untranslated. We try to translate them, I guess, because of the impact on users. See how you noticed and complained ;-) But it is a lost job. I translated, with a small but enthusiastic number of contributors, the first round of such files, the first time we did the Spanish translation. After perhaps two rounds, I refused to translate it again, seeing that on next round several thousands of the strings we had translated were lost. Actually, KDE has a very good team of translators. We learned a lot from them when we started. And it is still kde.org ;-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlW6CVYACgkQja8UbcUWM1xNbwEAiDgdz7PrbaInFuoix+ExIuIe MjhfMzYmTBFX/i33xe4A/jqowATES+CpXqEy4Jxoepb6T/gpJY+f4yGjdfgGN0+3 =zOoa -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 30 July 2015 at 06:49, Carlos E. R. <carlos.e.r@opensuse.org> wrote:

And factory, aka Tumbleweed, is not translated. We only translate the stable versions.

If this is a policy, I think 'we' should change it. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Donnerstag, 30. Juli 2015, 03:49:05 schrieb Carlos E. R.:

On 2015-07-30 03:26, Richard Brown wrote:

...

On 30 July 2015 at 06:49, Carlos E. R. <> wrote:

...

And factory, aka Tumbleweed, is not translated. We only translate the stable versions.

If this is a policy, I think 'we' should change it.

It is not a policy; it just is not feasible.

Some months ago, a member of the Spanish translation team invested a lot of effort in translating things on Tumbleweed, but he had to stop when he noticed that his translated texts were not appearing on TW, and we couldn't help it.

Translators can translate, but other people have to provide the translators with the texts to translate (*.pot files), and then other people have to apply those translations (*.po) back to the devel source files, and create the appropriate packages. I think that one of the complications is that bot groups (translators and developers) work on different servers (svn and git?). The details of that part are foggy to me, sorry.

This is a manual process, and I understand only one or two persons do it. Ask Karl Eichwalder for details. He needs help for handling Leap, there is currently no way to translate it, either.

But the end result is that this cycle is only done during the string freeze phase, ie, a bit before the RC, I suppose that because it is complicated and manual. There is no procedure in place for working on Tumbleweed, it would have to be automated.

Notice also that, even if that can be automated, it is big effort for translators to work on software that is changing from day to day. It takes time to translate (we are note professionals, yet we take pride and effort on it), and then a week later a dev changes a single comma on a string, and it is null. Has to be translated again. Obviously devs can change a lot of strings, causing a large part of the translation to have to be redone. Which is why on the roadmap there was a date for "string freeze".

About menus, Yamaban explained the issue, which is another complication on top of the above, general issue. The menus, the software description package, contains several thousand of entries, and every release has to be done again almost from scratch, previous work is lost. This discourages translators which avoid to work again on that bunch. It would be easier to translate those things upstream.

I hope this clarifies the situation a bit :-)

Yes, thank you. To me this seems that processes and responsibilities should be re-evaluated. As should be priorities. For instance UI-items should come first, I think. Doing the same cumbersome, time-consuming work over and over again really makes no sense. Do it once, on the last RC, and then only minor corrections. Except you get paid for it. But even then...I think this is stuff that could be done by, well, computers? ;) Regards! And hats off to the translators! Rainer Fiebig -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Carlos E. R. wrote:

Notice also that, even if that can be automated, it is big effort for translators to work on software that is changing from day to day. It takes time to translate (we are note professionals, yet we take pride and effort on it), and then a week later a dev changes a single comma on a string, and it is null. Has to be translated again.

As a translator of many free software applications, I’m not sure I understand this correctly. What I’m used to is this: 1. The translator translates the string. 2. The developer changes a single comma in the original (English) string. 3. The translation is automatically marked as ‘fuzzy’, which means that it’s not used, but still available. The original string is kept. In the translation editor the translator can see the new English string and which changes have been done (this is typically shown as coloured ‘diff’ output, showing which characters have been removed and added in the English string). 4. The translator updates the translation, by just removing the ‘fuzzy’ status (if the translation don’t need any changes), or by editing the translation (e.g., adding/removing the missing/extraneous comma). So for small changes in the English strings, it’s very quick to keep the translations updated. This is a very efficient way to work for both translators and developers. Does the translation system in openSUSE differ from this workflow? (It does use standard .po files, so I would expect it not to.)

About menus, Yamaban explained the issue, which is another complication on top of the above, general issue. The menus, the software description package, contains several thousand of entries, and every release has to be done again almost from scratch, previous work is lost.

-- Karl Ove Hufthammer E-mail: karl@huftis.org Jabber: huftis@jabber.no -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Carlos E. R. wrote:

On 2015-07-30 15:23, Karl Ove Hufthammer wrote:

...

So for small changes in the English strings, it’s very quick to keep the translations updated. This is a very efficient way to work for both translators and developers. Does the translation system in openSUSE differ from this workflow? (It does use standard .po files, so I would expect it not to.)

Yes, it is the same. The translator, a human, has to visually inspect both the new and the old strings, notice what is different, then apply changes to the translated strings.

It can be a comma, a spell correction in a word, a change of order in words, something subtle that provokes an important change on the target language...

For this he needs to be told that there are changes, download the file, open the editor (lokalize, probably), perhaps load the old and the current versions, save, upload...

Hm. I have started translating for openSUSE, but have more experience with KDE. There we don’t have to be told there are changes, as there are *always* changes (i.e., daily). :) And for downloading the files, we only have to run ‘svn up’ to fetch all updated files. Using the project view in Lokalize, we can easily see which files have new or changed string (and can sort the files by the number of untranslated or changed strings). And the coloured diff in Lokalize makes it extremely fast and easy to see what parts of the English strings have changed (this is a godsend for multiparagraph strings!), and to update the translation accordingly. It’s both fast and efficient.

Plus other people have to retrieve the .pots, and after translation, submit the .pos to the devs. Typically they wait to do this till they think that all the translators have finished.

I didn’t realise this. OK, this I see as a big problem. Why would the .po files have to be *submitted* to the developers? In KDE, the latest translations are *automatically* used whenever the developers decide to package the software (i.e., using build scripts). And the latest strings are automatically (daily) extracted from various applications into translation templates. No need for either the translators or the developers to worry about it at all (except when first setting up an application for translation).

Realistically, it takes days at least. Usually weeks.

What I mean is that even a minor change in the sources cause the whole process to rerun, and the current turnaround is rather weeks than days.

Hm, that’s scary, and an indication of a very bad workflow. It really should never take more than a day, and should not involve any people doing any work except just translating. That’s why we have computers! -- Karl Ove Hufthammer E-mail: karl@huftis.org Jabber: huftis@jabber.no -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Donnerstag, 30. Juli 2015, 16:41:59 schrieb Carlos E. R.:

On 2015-07-30 16:24, Karl Ove Hufthammer wrote:

...

Carlos E. R. wrote:

Hm. I have started translating for openSUSE, but have more experience with KDE. There we don’t have to be told there are changes, as there are *always* changes (i.e., daily). :) And for downloading the files, we only have to run ‘svn up’ to fetch all updated files. Using the project view in Lokalize, we can easily see which files have new or changed string (and can sort the files by the number of untranslated or changed strings). And the coloured

diff in Lokalize makes it extremely fast and easy to see what

parts of the English strings have changed (this is a godsend for multiparagraph strings!), and to update the translation accordingly. It’s both fast and efficient.

Well, lokalize, being a KDE program, is very well suited to the directory structure and procedure organization used by KDE, but apparently not so well to ours. Or at least, I haven't managed to do it well.

We do have an svn server, but few translators use it. Many use an intermediate platform, vertaal, that is used mostly for organization (who translates what and when). It is this platform which emails the translator assigned to a file that it needs work. The details of this depends on each language team.

...

...

Plus other people have to retrieve the .pots, and after translation, submit the .pos to the devs. Typically they wait to do this till they think that all the translators have finished.

I didn’t realise this. OK, this I see as a big problem. Why would the .po files have to be *submitted* to the developers?

The devs are on a different server, git, I think. I guess there is not a single directory that has all the catalogs, but probably many, which is why they have to be collected by people for submission. This is a part of the process I don't see, so I don't know how exactly it works.

This is not unique to openSUSE. The Translation Project is also convoluted: translators are told of pending work by email, retrieve the file via http download, then submit back via email. On other projects I participate (xine), I have to download the sources from packman, translate, then upload to a paste site that I can find (google drive, for instance), then post a link in an email to their mail list so that the devs them pick it.

Convolution seems to be the norm; only some projects, like KDE, have it very well organized :-)

Didn't help them in this case. They got outsmarted by a bug! ;) Rainer Fiebig -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Donnerstag, 30. Juli 2015, 17:21:03 schrieb Karl Ove Hufthammer:

Jay skreiv:

...

...

Convolution seems to be the norm; only some projects, like KDE, have it very well organized :-)

Didn't help them in this case. They got outsmarted by a bug! ;)

I believe this is an openSUSE bug, *not* a KDE bug.

This is the irony of it! ;) Regards! Rainer Fiebig -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-07-30 17:19, Karl Ove Hufthammer wrote:

Carlos E. R. wrote:

...

Well, lokalize, being a KDE program, is very well suited to the directory structure and procedure organization used by KDE, but apparently not so well to ours.

Ah, that’s true. I’ve been wondering why openSUSE has such a strange directory (and file naming) structure for translations. I would have guessed it was because it made things easier for the developers, but obviously it does not.

I don't know about devs, I only know about translators ;-)

Personally, for openSUSE translations, I use the the Pology summit workflow detailed at http://pology.nedohodnik.net/doc/user/en_US/ch-summit.html (but with a custom config file the Pology creator helped me with, since the openSUSE doesn’t use either of the two standard directory structures). The result is a standard directory structure for translation files (.po and .pot) files, just like for KDE, which means I can use the project viewer in Lokalize:

├── templates │ ├── activedoc │ │ ├── ad-blocks.pot │ │ ├── ad-contact.pot │ │ ├── ad-fields.pot │ │ ├── … └── langcode ├── activedoc │ ├── ad-blocks.po │ ├── ad-contact.po │ ├── ad-fields.po │ │ ├── …

It is similar. This is what I get on CVS (svn? I forget) for the 13.2 branch: |-- openSUSE-13_2-Branch | |-- lcn | | |-- 50-etc | | | |-- VERSION | | | |-- html-stats.sh | | | |-- i18n_branches.txt ... | | |-- 50-html | | | |-- MAINTAINERS | | | |-- Makefile.am | | | |-- help-boot | | | | |-- navi.html | | | | |-- opt.html | | | | |-- opt::help.html ... | | | |-- help-boot.html | | | |-- help-install | | | | |-- main.html | | | | |-- main::bits.html | | | | |-- main::driverupdate.html | | | | |-- main::failsafe.html | | | | |-- main::firmware.html ... | | | |-- html-help-install.pot | | | `-- projects.mk | | |-- 50-memory | | | `-- memory.es.po | | |-- 50-pot --> templates? | | | |-- MAINTAINERS | | | |-- RELEASE-NOTES-openSUSE.pot | | | |-- SUSEgreeter.pot | | | |-- apparmor-parser.pot | | | |-- apparmor-utils.pot | | | |-- apparmorapplet.pot | | | |-- bootloader.pot | | | |-- command-not-found.pot ... | | |-- 50-tools | | | |-- checked-fix-plural.awk | | | |-- checked.awk | | | |-- concat-html.sh | | | |-- desktop-files-extract.pl | | | |-- desktop-files-list.sh | | | |-- desktop-files-pull.sh | | | |-- desktop-files-split.sh | | | |-- desktop-files-update.sh | | | |-- desktop-files-update.urls | | | |-- fix-init.sh ... | | `-- es --> langcode? | | |-- Makefile.svn | | `-- po | | |-- RELEASE-NOTES-openSUSE.es.po | | |-- SUSEgreeter.es.po | | |-- apparmor-parser.es.po | | |-- apparmor-utils.es.po | | |-- apparmorapplet.es.po | | |-- bootloader.es.po | | |-- command-not-found.es.po And another for "packages" and another for "yast". I marked above what I think are the equivalent sections.

...

We do have an svn server, but few translators use it. Many use an intermediate platform, vertaal, that is used mostly for organization (who translates what and when). It is this platform which emails the translator assigned to a file that it needs work. The details of this depends on each language team.

OK. I thought most translators still used SVN. Yes, using a Web platform certainly makes thing less efficient. (But if people prefer it, who am I to argue, as long as I can still use SVN.)

I use both. I use svn to do the actual pulling and sending of files. But first, I use vertaal to locate a file that is asigned to me or to nobody, and I mark that I'm working on it, so that nobody else modifies it. Then I work directly on my copy of the file on my svn copy; but others instead pull the .po file using vertaal web interface. When finished, I just commit it, and others send it in a gz via same platform. This platform does some checking, and if passes, will commit the file in a cronjob sometime in the day. If not pass, will tell immediately the translator. Vertaal can also do other things, like apply changes in the pot to the po file. It's a flexible platform. It acts as intermediary to svn, yes, but most importantly, it controls assignation of files. This eases a lot the job of coordinators. Depending on the team, a translator can simply pick himself a free file. What it does not do is present some type of editor to do the actual translation job. That does exist, I think ubuntu does it that way.

...

The devs are on a different server, git, I think. I guess there is not a single directory that has all the catalogs, but probably many, which is why they have to be collected by people for submission. This is a part of the process I don't see, so I don't know how exactly it works.

OK. In KDE, all applications *used to be* on a single SVN server. Now, they’re scattered across different (mostly Git) servers. But I believe they are automatically fetched when building (or perhaps only when packaging) the applications.

That's the part that needs help currently.

...

This is not unique to openSUSE. The Translation Project is also convoluted: translators are told of pending work by email, retrieve the file via http download, then submit back via email.

There is also a script one can use for this. But I agree that The Translation Project translations process could be more streamlined!

The only actual problem I find with it is that although they send emails to translators to tell them of work pending, I rarely notice them, in the mass of emails from the robot.

...

On other projects I participate (xine), I have to download the sources from packman, translate, then upload to a paste site that I can find (google drive, for instance), then post a link in an email to their mail list so that the devs them pick it.

That sounds terrible!

It is. The issue is that their mail list server has a size limit for attachment, or a block, so that I simply can not attach the translations in the mail. Ah, I have to pull the pot from packman because their build tree doesn't have the pot files readily built. I don't remember the exact problem, I just found it easier to pull from packman. They don't do releases, I never know when there is work to do.

Luckily, for most applications I have translated, I have been given commit access to SVN. Some require patches attached to bug trackers or sent to e- mail lists. These are also the projects with the fewest number of (updated) translations …

Some are impossible: have a look at Alpine: last time I looked, the help texts were in the .pot. But each line a different string! We need a paragraph per string, more or less. Entire sentences at least.

...

Convolution seems to be the norm; only some projects, like KDE, have it very well organized :-)

Yes, we’re lucky in KDE. :)

Yes, you are :-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlW6YP0ACgkQtTMYHG2NR9XG6ACgi/b3GrVBFi/G681qtSJ5FLLK RrcAn2Ow5JU23E4IfK26ZES3AXxYeKI7 =jZsP -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Donnerstag, 30. Juli 2015, 10:30:05 schrieb Tomáš Chvátal:

Dne Čt 30. července 2015 00:42:02, Jay napsal(a):

...

I updated KDE Plasma from 4.x to 5.2.2 today in a 13.2 VM. Just to take a look.

The startmenu comprises 13 items. 3(!) of those are still in English and not in German (the default setting for that system). This is the same in almost every section I looked at: a mixture of German and English. I guess this will be similar with other languages.

And Plasma 5 has been launched a year ago or so, I think.

Now for my probably naive question: what the heck makes it so difficult or time-consuming to translate this stuff?

It cannot be the amount of text - this simply cannot be so huge. And translating "Recent documents" (startmenu) into German is not really a challenge. They have done it before.

Please give me a clue.

Those strings are actually translated, but there is bug in handling translations with openSUSE string update mechanisms. This means those translations are present on the system, but plasma5 has no knowledge of them.

KDE team is aware of this and they are trying to fix the problem. You will simply have to wait to have it fixed. Probably at some point before 42 release, because we can't afford to have it untranslated there :)

Ah - good to know! I was already considering to start arguing against including Plasma 5 in Leap.

With regards to translations to 42/Tumbleweed we are also looking into the problem and will provide some solution soon. But it has nothing to do with this particular problem.

The issue is tracked in following two bugs: https://bugzilla.suse.com/show_bug.cgi?id=904524 https://bugzilla.suse.com/show_bug.cgi?id=932158

Cheers

Tom

Thank you for this important information! Bugs happen - no problem with that! Regards! Rainer Fiebig -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Samstag, 1. August 2015, 12:57:24 schrieb Wolfgang Bauer:

That said, I'm not sure where the originally mentioned issue ("Recent Documents" not translated in the applications launcher) comes from, I see that here too. But I don't think it's related at all to that bug/missing patch or a not- installed lang package.

Actually the problem in this case is that openSUSE's Plasma5 packages install the translations to /usr/share/locale/kf5/, where they are apparently not found. Copy them (/usr/share/locale/kf5/xx/LC_MESSAGES/plasma_applet_org.kde.plasma.kicker.mo in this case) to /usr/share/locale/xx/LC_MESSAGES/ and the entries are correctly translated... Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org