Olav Pettershagen writes:

What are the implications if all translations are not finished by the end of the first cycle?

Does it merely mean that there will be more work during the second cycle for a particular language or will there be more "serious" implications - such as adminstrative problems for you?

Good questions :) It basically means, that strings are now "frozen". Developers will not change messages any more--only if there is a serious bug that needs fixing. Of course, you can finalize the tranlation during the 2nd cycle, but the sooner translations are available, the more you can test them. All translations submitted by Friday 20 will be present in the beta of the following week. -- Karl Eichwalder R&D / Documentation SUSE Linux Products GmbH GPG: 1024D/06EB882E B2A3 AF2F CFC8 40B1 67EA 475A 5903 A21B 06EB 882E --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Karl Eichwalder writes: Today, we want to start the second and final translation round. The YaST files are in and merged (only printer.pot with approx. 10 message will be updated next week). The LCN part is also mostly available, only some languages will need a remerging later the day or tomorrow. Let's hope the SVN server will be back soon; at the moment it is down. The initial announcement once again:

----------------------------------------------------------------------------

To: opensuse-translation@opensuse.org Subject: [opensuse-translation] openSUSE 10.2 Translation Roadmap and the Localization Portal From: Karl Eichwalder Date: Wed, 06 Sep 2006 13:54:22 +0200 Message-ID:

10.2 Software Translation Roadmap =================================

As usual, there will be two translation cycles:

2006-10-06 : 1st cycle starts 2006-10-20 12:00: 1st cycle ends

2006-10-27 : 2nd cycle starts 2006-11-04 12:00: 2nd cycle ends

That is ambitious--but the good news is, you as a team coordinator can submit the PO files to the SVN repository on your own. Team coordinators, please create an account on http://developer.novell.com and mail me your account name and your language. Subscribe yourself to the "dev" mailinglist that is announced at http://forge.novell.com/mailman/listinfo/suse-i18n-dev. All the other team members are encouraged to subscribe themselves to this list, too. (Aside, we must work out whether we actually need the opensuse-translation list.)

You can start working on the files immediately. Be warned, POT files are still a matter of change, and thus new and fuzzy strings will appear in PO files until the 1st translation cycle officially starts. Also be prepared to resolve check-in conflicts caused by daily merging.

Postpone the packages_* files. ATM, we do not intend to include these PDB related translations. So, do not waste your energy on these files!

openSUSE Localization Portal Launched =====================================

openSUSE is not only for developers. You can join your localization team and help translating openSUSE into your native language. Take a look at the Localization Portal for translation statistics of your language (cheers to Klára!): http://i18n.opensuse.org/stats/index.php.

Our project is stored at http://developer.novell.com/wiki/index.php/Suse-i18n -- anonymous checkouts are also possible. Find more info in the openSUSE wiki: http://en.opensuse.org/OpenSUSE_Localization_Guide http://en.opensuse.org/OpenSUSE_Localization_Developers_Information

-- Karl Eichwalder R&D / Documentation SUSE Linux Products GmbH GPG: 1024D/06EB882E B2A3 AF2F CFC8 40B1 67EA 475A 5903 A21B 06EB 882E --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Andreas Jaeger writes:

Unfortunately the svn server is broken and a new machine is currently set up, it will only be available on monday US time :-(

I just copied the YaST bundles to the FTP server; they will be available after the next mirror run, hopefully: ftp://ftp.suse.com/pub/suse/noarch/i18n/yast If you do not have the current .po files available, you can unpack the .tar.gz archive and use them for translation. -- Karl Eichwalder R&D / Documentation SUSE Linux Products GmbH GPG: 1024D/06EB882E B2A3 AF2F CFC8 40B1 67EA 475A 5903 A21B 06EB 882E --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Karl Eichwalder napisał(a):

Because of the delays during the last days we want to extent the translation deadline by approx. one week. Checkin deadline for the translations (YaST and lcn) now is

Friday, 2006-11-10 10:00 CET

Karl, I'm concerned with the level of activity in the svn repository. I thought there was a rule that during localization rounds the files are frozen, and no changes are made to them. Please, respect this rule! We spent more time comparing the versions of files in your repository and in the ours (we have one for our localizers) than actually translating the files! In our team there are 10 to 15 localizers, so when a round starts, I check out the files, distribute them among approximately 12 people, then wait for them to finish, and then I have to deal with the updates to the files I'd checked out. I understand that this is due to updates made by developers, but I'd appreciate if you waited till the end of the round (and then schedulle another one), or explicitly announced on the list, that an update was checked in. Most of the updates are about line numbers, and as such, they are irrelevant to translators. Luckily, they're easy to filter out. However, this is not the case with the files in which broken-line strings were changed into one-line strings (--no-wrap option) - it is more difficult to have them automatically ignored in diffs. (I usually leave these things untouched, as they are merged automatically during merging rounds). My point is, that it's difficult to follow the changes made to the translations. I've uploaded a diff that came out as a result of the following command issued in my local copy of lcn/pl/po: $ svn diff -r 2888:3818 --diff-cmd diff -x '-U 0' | grep -v "[+-]\#[^,]" Please take a look: http://smalolepszy.googlepages.com/lcn-2888-3818.diff These are the changes made to Polish LCN translations, and there are many new strings flagged as fuzzy, and some new ones as well. I can very easily merge the files I will get by tomorrow from my colleagues with the newest pot files sitting in Novell repo. But we will get new fuzzys this way, and we will need some time to go through them and check them. If you want me to submit a bug report about this, I surely will. Regards, Stanisław Małolepszy -- aviary.pl l10n team http://aviary.pl --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Hi Karl, just on: "Sometimes messages turn out to be weaky worded. If these messages are important, we will fix them." Can you expand on that a little please - for me it raises the following questions: 1) Do you mean that instances of weak messaging are caught by chance (as opposed to specifically reviewed)? 2) Who is rewording the translations - or do you ask the community to re-submit? I think this would be better... 3) Are changes/fixes recorded or tracked in any way? (If not, I really hope that they can be from now on so that we can give this feedback to Stanislaw and others) 4) Do you have examples of any "preferred" messages? If so, you and I should follow up separately as I'd like to add these examples to our Language Style Guides for distribution. (We may even be able to incorporate some of these into iTerm for you!). Thanks Anne

...

...

Karl Eichwalder 09/11/2006 09:23 >>> Stanis*aw Ma*olepszy writes:

Karl, I'm concerned with the level of activity in the svn repository. I thought there was a rule that during localization rounds the files are frozen, and no changes are made to them. Please, respect this rule!

Yes, we respect this rule, but the openSUSE developers have to fix bugs. That's the other side of the coin. The overall-goal is not to ship a 100% translated product, but to ship a good or excellent product. Here are some rules when we allow late minute changes to the pot files: If we detect "untagged" messages that the user may see if he uses openSUSE, we will mark them for translation and add them to the repository. Sometimes messages turn out to be weaky worded. If these messages are important, we will fix them. During the beta test we find situations that need to be handled by the GUI. Such files like update-desktop-files most likely will change every day. We do not expect you to translate all these new strings. I always notify you if an important change happens. Only work on the other messages if you have time. Always take into account how many messages openSUSE exist. Even if 100 messages are untranslated, it's just 0.x or 0.0x% or the pool. Additional note: Feeding the messages in a "private" repository always take time. Often it might be worth spending this time. In the long run I recommend to enhance the repository on Novell forge. If translation memories or other tools are missing, we should discuss them and then you can add them.

I understand that this is due to updates made by developers, but I'd appreciate if you waited till the end of the round (and then schedulle another one), or explicitly announced on the list, that an update was checked in.

There are conflicting goal. The sooner the messages are in, the sooner translators can work on them, and test them. But I think we can offer additional statistics about certain milestones. We shall discuss this with Klára and she probably will help us to implement such a feature after 10.2.

Most of the updates are about line numbers, and as such, they are irrelevant to translators. Luckily, they're easy to filter out. However, this is not the case with the files in which broken-line strings were changed into one-line strings (--no-wrap option) - it is more difficult to have them automatically ignored in diffs.

Yes, line numbers are sometimes difficult to handle. We can discuss the --no-wrap option. In the very past, developers and translators aked for it. Yes, you are not meant to update translations if files only differ in line numbers and wrapping. Before diffing it mostly works best to normalize the files first using msgcat without any option or with --sorted.

If you want me to submit a bug report about this, I surely will.

Most of your concerns are fair issues and we must make sure not to forget about them and to implement missing feature. Thus it might be a good idea to add some of them as enhancement requests. -- Karl Eichwalder R&D / Documentation SUSE Linux Products GmbH GPG: 1024D/06EB882E B2A3 AF2F CFC8 40B1 67EA 475A 5903 A21B 06EB 882E --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Karl Eichwalder writes:

svn log 50-pot/ | less

...

Unfortunately, it is not that easy to see the affected files with a glance and, as usual, my comments are rather terse ;-(

Berthold just told me using the -v switch you can see the affected files: ------------------------------------------------------------------------ r3711 | ddrewelow | 2006-11-05 13:40:59 +0100 (Sun, 05 Nov 2006) | 2 lines Changed paths: M /trunk/yast/50-pot/yast2-apparmor.pot Updates, fixes, new strings ------------------------------------------------------------------------ r3595 | keichwa | 2006-11-02 22:41:12 +0100 (Thu, 02 Nov 2006) | 1 line Changed paths: M /trunk/yast/50-pot/installation.pot update on account of [Bug 215697] ------------------------------------------------------------------------ r3352 | keichwa | 2006-11-01 22:21:55 +0100 (Wed, 01 Nov 2006) | 1 line Changed paths: M /trunk/yast/50-pot/printer.pot update as announced last week ------------------------------------------------------------------------ Not too bad :-) -- Karl Eichwalder R&D / Documentation SUSE Linux Products GmbH GPG: 1024D/06EB882E B2A3 AF2F CFC8 40B1 67EA 475A 5903 A21B 06EB 882E --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Yes, I have that from earlier Klara - but thanks for sending this on.

So - what I meant was, our *individual linguistic* style guides, ie we have one customised for each locale.

So within each of these, I am suggesting we add some translation examples so that translators are informed on what we prefer from the outset.
Of course, we can only recommend here....volunteers can choose whether they want/need to read these materials or not.  But the feedback from the community so far is that they do like having access to this content.

I can follow up with you/Karl to progress this.

D*kuji
Anne


>>> Klara Cihlarova  09/11/2006 13:17 >>>
>4) Do you have examples of any
> "preferred" messages?
> If so, you and I should follow up separately as I'd like to add these
> examples to our Language Style Guides for distribution. (We may even be
> able to incorporate some of these into iTerm for you!).
>
There is a YaST style guide at 
http://forgeftp.novell.com/yast/doc/SL10.1/styleguide/index.html. 

The KDE/GNOME specific applications should use messages prefered in the 
KDE/GNOME project.
--
Klara
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org 
For additional commands, e-mail: opensuse-translation+help@opensuse.org 


---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org
For additional commands, e-mail: opensuse-translation+help@opensuse.org

Karl Eichwalder napisał(a):

Additional note: Feeding the messages in a "private" repository always take time. Often it might be worth spending this time. In the long run I recommend to enhance the repository on Novell forge. If translation memories or other tools are missing, we should discuss them and then you can add them.

I'm sorry, I'm afraid I didn't get this paragraph.

...

I understand that this is due to updates made by developers, but I'd appreciate if you waited till the end of the round (and then schedulle another one), or explicitly announced on the list, that an update was checked in.

There are conflicting goal. The sooner the messages are in, the sooner translators can work on them, and test them.

I understand this perfectly. I have to admin, that it wouldn't be much of a problem, if it hadn't been for two fectors: 1) since I assumed that translation round equals total string freeze, I allowed myself to send the files to my colleagues instead of encouraging them to update their local copy of Novell repository every time they start to translate. 2) the prolonging downtime of the Novell repository made me think, that I was right to do so. Do you have any statistics on how many strings you usually have to update during a translation round? Or rather rough estimates, as opposed to exact statistics. Do all of them have a bug report associated with them? Maybe we could make an mail alias that would forward bugmail to all l10n coordinators, and that would be CC'ed to every such a bug? This would make it easy to track the updates for us.

Yes, line numbers are sometimes difficult to handle. We can discuss the --no-wrap option. In the very past, developers and translators aked for it. Yes, you are not meant to update translations if files only differ in line numbers and wrapping. Before diffing it mostly works best to normalize the files first using msgcat without any option or with --sorted.

I think as well, that the --no-wrap option is a good idea - it makes it easy for examlpe to quickly diff the po files and look for new strngs by greping msgstr "". (Without --no-wrap msgstr "" may not only indicate a new string, but also a string that has been wrapped). Also, thank you for the hint on normalizing the po files - it seems very useful. Thank you for your time on this. Best regards, Stanisław Małolepszy -- Aviary.pl l10n team http://aviary.pl --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Hello everybody, I just installed openSUSE 10.2 beta and saw that Zen (updater, installer, remover) is still half-translated into french. It's kind of boring because it's an "important" (or really visible) software for the GNOME users. I downloaded the current version of the SRPM (7.1.100), so I have the current fr.po file. I'm ready to quickly translated it. Can I? In the positive case, where I send the updated file? If someone can tell me more, that would be nice :) Regards, Gilles -- Gilles Fabio aka "Play" Weblog : http://gilles.fabio.free.fr/blog OpenPGP : 320F31F8 (pgp.mit.edu) Sent from : SUSE Linux Enterprise Desktop 10 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Hi Gilles, Thank you very much for your offer to help with the translation of Zen-updater. However, French is one of the languages that we translate internally at Novell ( http://en.opensuse.org/OpenSUSE_Localization_Teams for more information) I have brought this issue to the attention of our team and we aim to have it fixed for the next build. regards

...

...

On Mon, Nov 13, 2006 at 4:52 PM, in message <1163436741.10585.19.camel@sledbox.homenetwork>, Gilles Fabio wrote: Hello everybody,

I just installed openSUSE 10.2 beta and saw that Zen (updater, installer, remover) is still half- translated into french. It's kind of boring because it's an "important" (or really visible) software for the GNOME users.

I downloaded the current version of the SRPM (7.1.100), so I have the current fr.po file. I'm ready to quickly translated it. Can I? In the positive case, where I send the updated file? If someone can tell me more, that would be nice :)

Regards, Gilles

--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org

Karl Eichwalder napisał(a):

If you copy files from and to the Novell repository, it takes time. I'd like to see us improving the Novell repository in a way that private repositories become superfluous.

Let me briefly describe the situation we deal with and the ways we've been trying to solve the problems. Out of about 10 to 15 people in out team, only 2 have the write access to Novell Forge repository. This is reasonable, of course, since 2 seems like enough. We make use of our private repository (also managed with svn), located on our server aviary.pl. This one is open for write access to every translator in our team. To facilitate synchronising the two repositories, I've started to write very simple Bash scripts, which automate the process. One of them is called nvl-sync, and it takes one obligatory argument (aviary or forge) and one optional one (--no-merge) 1) ./nvl-sync forge This command is used to transfer the files from our private repo to yours. It is issued in the working copy of Novell Forge repository. It exports the files from aviary.pl repo, and copies them over the files in the local copy. It is issued only by either of the two persons with the write access to Novell Forge - otherwise it makes little sense ;-) 2) ./nvl-sync aviary This command is issued to transfer the files from Novell Forge to the Aviary.pl repository. We encourage translators to issue it every time they start working - this way we ensure, that they're working with the newest version of translation catalogues. It works by exporting pot files form Forge repository, po files from the ours, merging them and copying them over the files currently located in local copy of Aviary.pl repository. We merge files instead of just getting po's from your server, because that was the easiest way we could make commits to our repo safe. Consider this scenario: a) a translator gets the newest po's from the Forge, they translate a few strings and commit the changes to our repo. b) an other translator gets the newest po's from the Forge (the very same as in A), they translate a few strings and commit their changes to our repo *overwriting* the files changes by the first translator. c) a person with write access to the Forge synchronises the repositories As you can see, one of the solutions would be to synchronise repositories right after every single commit to our repository, which is obviously impossible. The other is to merge pot files (newest strings) with our po files (newest translations). 3. ./nvl-sync aviary --no-merge This command is reserved for special occasions, like the merge rounds you sometimes run. It gets po files from the Forge and copies them over to our repo. This is very useful, since this way we are able to use your translation memory tools, and we transfer better po files over to our repo (more exact matches, better fuzzy matches). BTW. could you point me to some recommendable resources about translation memory technologies? Currently we use a few compendia files merged from files we'd beed working on during the localisation of Now, for a totally different kettle of fish: Have you considered migrating form SVN to a distributed version control system? I am aware that your svn server itself is rather a new addition to the localisation process, but maybe you could give tools like darcs and bzr a thought? I read also about DVCS called svk, which started as an SVN wrap-around, and now has developed into something more mature. Not sure how well it works, tough, I don't have any experience with it.

Maybe, adding pootle to our site would be a win. That's something to be evaluated after 10.2 (see https://bugzilla.novell.com/show_bug.cgi?id=208982 )

This definitely sounds like a good idea. Especially if you want to lower the barriers to entry for the community. We spent considerable amount of time explaining newcomers how to use svn and KBabel or poEdit. And I'm still willing to do that of course, although pootle seems incredibly appealing :-)

In the past we agreed that "approx. 10%" is allowed for the 2nd round. I'd like to avoid additional bugzilla mails. Maybe, it is already possible to filter the opensuse bugmails somehow.

Fot the time being, your annoucments on the list are very helpful. I've also written a small script to easily display changes made to pot files each time I do svn up. BTW. What is the definitive deadline for submitting the translations so that they land in openSUSE 10.2? We have some new strings in yast2-apparmor and html-help-install that need to be taken care of. Best regards, Stanisław Małolepszy -- aviary.pl l10n team http://aviary.pl --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org