[libbonobo] Created branch gnome-2-30
The branch 'gnome-2-30' was created pointing to: 86915e2... Updated Hebrew translation. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Commit gettext .po files without extra comments
Hi all, [Since this is a cross-mailinglist email, please use reply-to-all and keep CC's when replying (unless this type of emails are frowned upon)] For two reasons, I think we should store gnome translations in the git repositories without the comments in the file that specify the location of the string with filename and line number. This information changes between almost every update of the file and is of no use after having finished updating the .po. 1) This information is not useful in the diff, it makes it much longer than it should be, with lots of noise. Here is an example commit without comments: http://git.gnome.org/browse/kupfer/commit/?id=12a98710951291b19e97b4b2caf932f40025776d Here is one with comments: http://git.gnome.org/browse/kupfer/commit/?id=934b87fccf3e5aeeb64d66780f24e0e80417c1ca In this case, the difference is not that big. And the actual content of the translations is very good in both changes, I am sure! The second reason is just as important in the long run 2) Over time, the line turnover will be much lower if we don't store these location comments with each revision. Over time, this will save lots of megabytes of version control history as the file history will compress much better. These location comments help the translator, and of course they will be there for this purpose. The comments are inserted like normal by 'intltool-update' and will be there if you edit the file. It is only when you run 'git diff' and then 'git commit' that the files will be displayed without the comments. It is only the filename+line comments that are stripped, other context information is kept intact. How to enable this? In Kupfer, this is enabled by editing two files: .gitattributes (shared version-controlled file) and .git/config (the user's local repository-specific configuration file). The .po file has to be listed in the .gitattributes file like this, to configure it with a "filter":: /po/sv.po filter=cleanpo Every user of the listed language must then insert the following definition of the 'cleanpo' filter into .git/config:: [filter "cleanpo"] clean = grep -v -E "^#: " This "cleanpo" is not something I can configure centrally from Kupfer; this is because of git's logic that I can't force arbitrary programs to run on other people's clones of the repository. That is obviously correct. That makes this scheme opt-in. I hope that this email explains how Kupfer translators can enable this for their language (if they want to!). I have added the same instructions to the actual .gitattributes file: http://git.gnome.org/browse/kupfer/tree/.gitattributes I have also sent this email to gnome-i18n because I want your feedback on this proposal. Summary: Filename+line comments are still available when updating the .po file, but not shown in diffs or stored in the repository history. All translators have to opt-in. Ulrik ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String additions to 'ekiga.master'
Le vendredi 04 juin 2010 à 10:08 +0200, Eugen Dedu a écrit : > On 03/06/10 20:43, Andre Klapper wrote: > > Am Donnerstag, den 03.06.2010, 20:30 +0200 schrieb Eugen Dedu: > >> We do not yet know which version will be released with gnome 2.30. So I > >> reverted the change, sorry for bothering you. > > > > GNOME 2.30 was already released two months ago. According to > > http://ftp.gnome.org/pub/GNOME/desktop/2.30/2.30.0/sources/ Ekiga 3.2.6 > > was used. The GNOME schedule can be found at > > http://live.gnome.org/TwoPointThirtyone/ . > > > >> I still do not understand why this constrain. It seems to me that the > >> natural solution is that 1-2 months before each release, the branch (or > >> the HEAD if the branch does not exist) enters string freeze, and before > >> that everything is allowed. > > > > Exactly. > > > >> This gives translators 1-2 months to work > >> on translations. But we are now four months away from the release and > >> we cannot make string changes for this release... > > > > You did not branch Ekiga yet after GNOME 2.30 was released. And all the > > branches of those apps used for GNOME 2.30 are string frozen for all > > times and one day. > > So branch Ekiga for gnome-2-30, gnome-2-30 will be used for more stable > > releases of Ekiga in GNOME 2.30, and feel free to changes any strings in > > git master which will be branched to gnome-3-0 in a few months. Or so. > > To resume: if I make a branch called gnome-2-30 from current stable > branch (gnome-2-26), it will automatically become current stable branch > and will be string frozen forever, while master becomes ok for string > changes until 1-2 months before gnome 3.0, cf. its roadmap. Is all that > right? The reasoning is right, but as you told us that GNOME 2.30 shipped ekiga from the stable gnome-2-26 branch, you do not have to create yet another gnome-2-30 stable branch. I just fixed l10n.gnome.org to consider gnome-2-26 as the branch used for GNOME 2.30. So you can now freely make string changes in master. In the future, please inform gnome-i18n and fix JHBuild moduleset [1] to reflect using a stable branch for a specific GNOME release. Claude [1] http://git.gnome.org/browse/jhbuild/tree/modulesets/gnome-suites-2.30.modules ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String additions to 'ekiga.master'
On 03/06/10 20:43, Andre Klapper wrote: Am Donnerstag, den 03.06.2010, 20:30 +0200 schrieb Eugen Dedu: We do not yet know which version will be released with gnome 2.30. So I reverted the change, sorry for bothering you. GNOME 2.30 was already released two months ago. According to http://ftp.gnome.org/pub/GNOME/desktop/2.30/2.30.0/sources/ Ekiga 3.2.6 was used. The GNOME schedule can be found at http://live.gnome.org/TwoPointThirtyone/ . I still do not understand why this constrain. It seems to me that the natural solution is that 1-2 months before each release, the branch (or the HEAD if the branch does not exist) enters string freeze, and before that everything is allowed. Exactly. This gives translators 1-2 months to work on translations. But we are now four months away from the release and we cannot make string changes for this release... You did not branch Ekiga yet after GNOME 2.30 was released. And all the branches of those apps used for GNOME 2.30 are string frozen for all times and one day. So branch Ekiga for gnome-2-30, gnome-2-30 will be used for more stable releases of Ekiga in GNOME 2.30, and feel free to changes any strings in git master which will be branched to gnome-3-0 in a few months. Or so. To resume: if I make a branch called gnome-2-30 from current stable branch (gnome-2-26), it will automatically become current stable branch and will be string frozen forever, while master becomes ok for string changes until 1-2 months before gnome 3.0, cf. its roadmap. Is all that right? -- Eugen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String additions to 'ekiga.master'
Il giorno gio, 03/06/2010 alle 20.30 +0200, Eugen Dedu ha scritto: > > > > Yes, of course, if you confirm that the version released in GNOME 2.30 > > is from the 2.26 branch, it is even the right thing to do. > > We do not yet know which version will be released with gnome 2.30. So I > reverted the change, sorry for bothering you. > > I still do not understand why this constrain. It seems to me that the > natural solution is that 1-2 months before each release, the branch (or > the HEAD if the branch does not exist) enters string freeze, and before > that everything is allowed. This gives translators 1-2 months to work > on translations. But we are now four months away from the release and > we cannot make string changes for this release... > Just a little OT: this misunderstanding of release time and versions could be a good example for new moduleset proposal. :) ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
