Re: [ANNOUNCE] brasero-0.8.4 released and branched
On Thu, Jan 8, 2009 at 2:14 AM, Kenneth Nielsen k.nielse...@gmail.com wrote: I don't think the new branch has been added til damned lies under the brasero module. Would be nice to have it there, if someone has the time to do it. Regards Kenneth Nielsen brasero_0_8 branch added to DL. Thanks. 14. dec. 2008 18.16 skrev Philippe Rouquier bonfire-...@wanadoo.fr: Hi all, The title says it all: a new version of brasero has just been released. It has also been branched to start developping new features. trunk will now host development version while the stable version will be in branches/brasero_0_8. In this release we tried to address some of the problems that were raised during the discussion about brasero integration into GNOME: - strings have been fixed (big thanks to all translators who helped fixing the strings and who translated the new ones) - integration with other apps have been pushed a bit further (btw, rhythmbox patch awaits review in bugzilla). On this topic, next version of brasero should be split between a library and the application itself. A plugin for totem is also in the works. Other improvement and fixes: - Fixed translation issues - HIG fixes - 557561 – Brasero don't recognize empty disk - 556449 – Session error : Insufficient space on media when copying an audio CD (same problem with trunk) - Fix GTK+ includes - #560525 – Add feedback about performed tasks - #560539 – Brasero doesn't copy track album info to audio CD - #Bug 560153 -- brasero crashed with SIGSEGV in brasero_data_project_node_to_uri() - #559105 – video could use same thumbnails as nautilus - #558213 – There should be a proper name for color picker button. - #561590 – Flickering Project Size Estimation dialog - #561050 – Brasero Hangs after trying to add mp3 files in an Audio Project - #558291 – Crash after New Audio Project and change path into folder /etc - #559107 – Never resume last used project by default - #560365 – Image creation breaks when disk is out of space - #562705 – brasero passes GTK_DISABLE_DEPRECATED and co unconditionally - #549119 – no space in /tmp given a not informative error - #561683 – No status whilst copying data DVD to DVD/ISO after 2048MB copied. - #560913 – preview of large images - #563989 – brasero crashs on fifo-files - #564397 – Use g_timeout_add_seconds where possible Updated translations: * ro.po: New Romanian translation by Adi Roiban a...@roiban.ro * da.po: Danish translation by Mads Lundby * fr.po: Updated French translation by Claude Paroz cla...@2xlibre.net * hu.po: Translation updated by Gabor Kelemen kelem...@gnome.hu * et.po: Translation updated by Mattias Põldaru * zh_HK.po: Updated Traditional Chinese translation(Hong Kong) by Chao-Hsiung Liao j_h_l...@yahoo.com.tw * zh_TW.po: Updated Traditional Chinese translation(Taiwan) by Chao-Hsiung Liao j_h_l...@yahoo.com.tw * fi.po: Updated Finnish translation by Ilkka Tuohela h...@iki.fi * de.po: Updated German translation by Mario Blättermann mari...@svn.gnome.org * cs.po: Updated Czech translation by Adrian Gunis * sv.po: Updated Swedish translation by Daniel Nylander p...@danielnylander.se * pl.po: Updated Polish translation by Tomasz Dominikowski tdominikow...@aviary.pl * es.po: Updated Spanish translation by Jorge Gonzalez jorgeg...@svn.gnome.org * lt.po: Updated Lithuanian translation by Gintautas Miliauskas gin...@akl.lt * nb.po: Updated Norwegian bokmål translation by Kjartan Maraas kmar...@gnome.org And many other bugs that were fixed before they were reported in bugzilla. Thanks to all the people who contributed to this release through patches, translations, advice, artwork, bug reports. Regards, Philippe ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
Well I think there is really more than one discussion now in this
thread. For my own sake, I'm a commiter and translator. I _want_ to be
able to get the source of a branch (that's just my choise), so if what
is written above is true, that I can still do that and it wont fill up
terribly more (or perhaps even less) on my HD, then it doesn't really
matter to me what system we use. I should be able to learn 6 commands
in any (D)VCS.
Then there is the other discussion, about what kind of work practices
it is really reasonable to ask translators to use (i.e. how much you
can ask them to download and what they need to do to translate). I
that sense, as long as git does not make anything any worse, then
there really shouldn't be an issue switching.
1. Translators can always get an updated po-files from damned lies
(git or no git)
2. If they want to get the po-file from source code then they can stil
do that (nomatter whether it is git or svn, and apparently with no
bigger downloads)
3. If they want to just get the source code to figure out the context
of strings, then they can stil do that (nomatter whether it is git or
svn, and apparently with no bigger downloads)
So if what I have understood about how this system works, I don't see
that big fuss. No improvements for us, but no disadvantages either.
Regards Kenneth Nielsen
2009/1/8 Simos Xenitellis simos.li...@googlemail.com:
On Thu, Jan 8, 2009 at 1:19 AM, Shaun McCance sha...@gnome.org wrote:
Hi Simos,
I don't want to detract from this conversation, because I think
it's important to consider how this would impact all of Gnom's
contributors, including translators, documentation folks, etc.
A switch would have at least some impact on everybody, and we
need to know how to deal with problems.
But...
Scenario A
= Using command line tools, we add a translation to the main repository.
Assume the repository is git://git.gnome.org/gnome-games.git
we make a local copy by 'cloning' the repository ('checkout' is
something different in git)
git clone git://git.gnome.org/gnome-games.git
This would create a very big tree, because it would make a full
offline copy, with all the history for the last ten years or so. When
we use SVN, a checkout of gnome-games is 124MB. The approximate size
of a 'git clone' should be quite larger. My test with 'git-svn clone'
was not conclusive (due to the way it works, it is very slow, I
stopped after an hour, which it downloaded 74MB).
I want to first point out that it's slow because it's git-svn.
I don't want people to think it would be this terribly slow if
we were using git. Cloning from a git server is quite fast.
More importantly, you'd be surprised at just how small a git
clone actually is. I have both a git clone and an svn checkout
of gnome-doc-utils. The svn checkout is 38MB. The git clone
is 26MB. Seriously, it's smaller. And the git clone has more
commits that aren't in SVN yet.
Hi Shaun,
This is the kind of information we need. That a possible move to git
will not cause issues with the current translation practices.
Therefore, for a coordinator that wants to update a translation the
manual way, the steps would be something like
1. Get a copy of the repository for the package (i.e. gnome-games)
$ git clone git://git.gnome.org/gnome-games.git
Initialized empty Git repository in /tmp/gnome-games/.git/
remote: Counting objects: 8728, done.
remote: Compressing objects: 100% (8712/8712), done.
remote: Total 8728 (delta 3431), reused 0 (delta 0)
Receiving objects: 100% (8728/8728), 71541.07 KiB | 239 KiB/s, done.
Resolving deltas: 100% (431/431), done.
$ _
2. Update the translation
$ cd gnome-games/po
$ intltool-update el
edit the PO file..
3. Commit first the translation to the local copy of the repository.
$ git commit -a -m Updated my translation
Created commit 22783ff: Updated translation.
1 files changed, 1 insertions(+), 0 deletions(-)
$ _
4. Push the change to the remote repository at git.gnome.org
$ git push
Counting objects: 5, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 316 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
To g...@git.gnome.org:simos/gnome-games.git
ff4bf15..22783ff el - el
$ _
5. That's it!
A practical comparison between git and other DVCSs (and SVN) is at
http://www.whygitisbetterthanx.com/
Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
Le jeudi 08 janvier 2009 à 01:16 -0500, Thomas Thurman a écrit : 2009/1/7 Sharuzzaman Ahmat Raslan sharuzza...@gmail.com: What I care is my language po file. Maybe around 15KB. Why should I download the whole bunch of data while the one that I need is just a small fraction of it. Indeed, why should you? You can get it from Damned Lies, can't you? The problem is when you want to commit (push) the result upstream. With svn you can just checkout the po directory. I fear this is not possible with git (or other DVCS). But until git is officially in production, we should have the time to develop the missing piece which is to commit directly from the uploaded po file on the 'vertimus' section of l10n.gnome.org. Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
Thomas Thurman írta: 2009/1/7 Sharuzzaman Ahmat Raslan sharuzza...@gmail.com: What I care is my language po file. Maybe around 15KB. Why should I download the whole bunch of data while the one that I need is just a small fraction of it. Indeed, why should you? You can get it from Damned Lies, can't you? Because I want/have to do $ git push Or can git check out only a single directory or file? I seriously don't know, so don't take it as an offence. I'm asking this because checking out anything other than $LANG.po and Changelog, optionally LINGUAS is not really necessary for doing translations. (CVS could do this! ;)) With SVN, we have to check out at least the po directory - not much more data, but still worse than CVS wrt to saving badwidth. Taking one more step backwards and having to download an entire repo would be quite bad in this regard - at least for those with limited bandwidth and until Transifex saves them. Regards Gabor Kelemen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: [ANNOUNCE] brasero-0.8.4 released and branched
Le mardi 16 décembre 2008 à 01:44 +, Luis Medinas a écrit : On Sun, 2008-12-14 at 19:09 +0100, Andre Klapper wrote: Hi, Am Sonntag, den 14.12.2008, 18:16 +0100 schrieb Philippe Rouquier: The title says it all: a new version of brasero has just been released. It has also been branched to start developping new features. trunk will now host development version while the stable version will be in branches/brasero_0_8. On this topic, next version of brasero should be split between a library and the application itself. A plugin for totem is also in the works. So the proposal for inclusion in GNOME 2.26 refers to the brasero_0_8 branch and not to trunk, I assume? Need to know for testing and translations. This is Philippe decision i'm not sure if we can deliver all plans for 0.9 (the library) that were proposed during the inclusion thread. Please give us a day or two to give a final answer about it. Maybe it's too late for other modules adopt the library if it's the idea. Ping. Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
PO files not found on l10n.gnome.org
Hemmm... it seems that all PO file (for all modules and releases) can't be found on l10n.gnome.org. Trying for example http://l10n.gnome.org/POT/empathy/HEAD/empathy.HEAD.fr.po (the URL pointed by download icon for empathy - GNOME 2.26 French) the result is Not Found The requested URL /POT/empathy/HEAD/empathy.HEAD.fr.po was not found on this server. Apache/2.2.8 (Ubuntu) DAV/2 SVN/1.5.1 PHP/5.2.4-2ubuntu5.4 with Suhosin-Patch mod_scgi/1.12 Server at l10n.gnome.org Port 80 Could someone check and fix it, better if ASAP :) Cheers, Luca ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: PO files not found on l10n.gnome.org
Le jeudi 08 janvier 2009 à 12:10 +0100, Luca Ferretti a écrit : Hemmm... it seems that all PO file (for all modules and releases) can't be found on l10n.gnome.org. Trying for example http://l10n.gnome.org/POT/empathy/HEAD/empathy.HEAD.fr.po (the URL pointed by download icon for empathy - GNOME 2.26 French) the result is Not Found The requested URL /POT/empathy/HEAD/empathy.HEAD.fr.po was not found on this server. Apache/2.2.8 (Ubuntu) DAV/2 SVN/1.5.1 PHP/5.2.4-2ubuntu5.4 with Suhosin-Patch mod_scgi/1.12 Server at l10n.gnome.org Port 80 Could someone check and fix it, better if ASAP :) Sorry, that's the URL composition that was broken. Fixed. http://l10n.gnome.org/POT/empathy.HEAD/empathy.HEAD.fr.po Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
Claude Paroz and Gabor Kelemen shared my concern very well. Thanks. 2009/1/8 Gabor Kelemen kelem...@gnome.hu Thomas Thurman írta: 2009/1/7 Sharuzzaman Ahmat Raslan sharuzza...@gmail.com: What I care is my language po file. Maybe around 15KB. Why should I download the whole bunch of data while the one that I need is just a small fraction of it. Indeed, why should you? You can get it from Damned Lies, can't you? Because I want/have to do $ git push Or can git check out only a single directory or file? I seriously don't know, so don't take it as an offence. I'm asking this because checking out anything other than $LANG.po and Changelog, optionally LINGUAS is not really necessary for doing translations. (CVS could do this! ;)) With SVN, we have to check out at least the po directory - not much more data, but still worse than CVS wrt to saving badwidth. Taking one more step backwards and having to download an entire repo would be quite bad in this regard - at least for those with limited bandwidth and until Transifex saves them. Regards Gabor Kelemen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n -- Sharuzzaman Ahmat Raslan ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
Jumping in in the middle again, with some experience from Mozilla after our switch to hg: One of they key questions when moving to a dvcs is what goes into which repo. This isn't really a requirement of a dvcs, but seems to come with the design of at least hg, and from glancing at it, git, too. DVCSes are bad at partial clones. In hg it's straight out impossible, and I haven't seen an obvious way in git. From my understanding, this comes from having a unique identifier for a repo so that you know where local commits would go when you push back upstream or round-robin or in circles and whatnot. What we do in Mozilla is: - one repo for Firefox and Toolkit - one repo for Thunderbird and Calendar and most parts of SeaMonkey - helluva more repos on hg or cvs for SeaMonkey - one repo for each localization for all three products The rationale for using a single repo per locale, and to not mirror the split in the en-US products was to optimize for smaller teams, where it's mostly one person working on everything anyway, and to not have them go through 5 repos for one locale. The downside is that for bigger teams with more than one committer, each contributor ends up having to pull and merge other apps and contributions before being able to push their own changes. In particular as we only allow one head per named branch on the repos. (User repos don't have that constraint, though.) There has been a rather lengthy discussion in our community if that's the right choice, both on the en-US side and the l10n side. The benefits of a DVCS just ask for a different set of compromises, sadly. I can't really tell which setup would be right for GNOME, as I don't know the community nor the module structure well enough, but if you have concrete questions, I'll try to come up with concrete answers. Another thing, release tags are a common source of grief, as that's a given landing on the l10n repos that are not done by the localization teams, and thus require them to pull and merge, or not, depending on their local status. HTH Axel 2009/1/8 Gabor Kelemen kelem...@gnome.hu Thomas Thurman írta: 2009/1/7 Sharuzzaman Ahmat Raslan sharuzza...@gmail.com: What I care is my language po file. Maybe around 15KB. Why should I download the whole bunch of data while the one that I need is just a small fraction of it. Indeed, why should you? You can get it from Damned Lies, can't you? Because I want/have to do $ git push Or can git check out only a single directory or file? I seriously don't know, so don't take it as an offence. I'm asking this because checking out anything other than $LANG.po and Changelog, optionally LINGUAS is not really necessary for doing translations. (CVS could do this! ;)) With SVN, we have to check out at least the po directory - not much more data, but still worse than CVS wrt to saving badwidth. Taking one more step backwards and having to download an entire repo would be quite bad in this regard - at least for those with limited bandwidth and until Transifex saves them. Regards Gabor Kelemen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Wrong 'action' dates on l10n.gnome.org
Example: http://l10n.gnome.org/users/Deindre/ Flavia claimed her translations this morning (Jan 08, 2009) but the webpage reports Dec 30, 2008. A similar issue occurred to me working on alarcate. As you can see here[1] the last action (committed) is dated 2009-01-06 14:09, but the state label on top reports 2009-01-01 10:37 p.m. About this topic, may I also propose two enhancements? * add the ability to localize dates/times and/or allow them to be user configurable. If you access to page [1] using en as browser language, you have: state date using English (WW DD MM YY HH:MM AM/PM) format; POT file update date using UTC, actions dates using local times. IMHO those dates/times should all use the same format, specified in damned-lies PO or chosen by single user. * add the ability to sort summaries (users and releases) by dates. Example: go to Italian summary for GNOME 2.26 release[2] (note by now we are just experimenting/testing with new l10n.g.o, only few modules have a state). Modules are listed in alphabetical order. From a coordinator point of view, could be good sort them by state-date, in order to check and poke people that claimed a translation for a long time and never uploaded it. Cheers, Luca. [1] http://l10n.gnome.org/vertimus/367/345/82 [2] http://l10n.gnome.org/languages/it/gnome-2-26/ui/ ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: New Coordinator
Le mardi 06 janvier 2009 à 23:27 +0100, Matic Žgur a écrit : Hello, I would like to inform you, that I resign from being the coordinator of Slovenian translation team and I would like to suggest Matej Urbančič as the new coordinator since he is very active with his translation efforts and already has svn account. Thank you all for your help, Matic Žgur I switched your roles in the Slovenian team: http://l10n.gnome.org/teams/sl/ Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Wrong 'action' dates on l10n.gnome.org
2009/1/8 Luca Ferretti elle@libero.it Example: http://l10n.gnome.org/users/Deindre/ Flavia claimed her translations this morning (Jan 08, 2009) but the webpage reports Dec 30, 2008. A similar issue occurred to me working on alarcate. As you can see here[1] the last action (committed) is dated 2009-01-06 14:09, but the state label on top reports 2009-01-01 10:37 p.m. Fixed on trunk. We need a mailing list to talk about Damned-Lies :) ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: New Coordinator
It seems the change was successful. Thanks. Matej On Thu, Jan 8, 2009 at 2:03 PM, Claude Paroz cla...@2xlibre.net wrote: Le mardi 06 janvier 2009 à 23:27 +0100, Matic Žgur a écrit : Hello, I would like to inform you, that I resign from being the coordinator of Slovenian translation team and I would like to suggest Matej Urbančič as the new coordinator since he is very active with his translation efforts and already has svn account. Thank you all for your help, Matic Žgur I switched your roles in the Slovenian team: http://l10n.gnome.org/teams/sl/ Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Wrong 'action' dates on l10n.gnome.org
Am Donnerstag, den 08.01.2009, 16:14 +0100 schrieb Stéphane Raimbault: Fixed on trunk. We need a mailing list to talk about Damned-Lies :) gnome-i18n-devel-list exists but it has never been used. ;-) andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: New release of Damned Lies with Vertimus included
Just trying to understand ... So, can I also change the faulty info on the http://l10n.gnome.org/teams/ and http://l10n.gnome.org/languages/sl/ ? Web page link is corrupt. Matej ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Wrong 'action' dates on l10n.gnome.org
Le jeudi 08 janvier 2009 à 16:38 +0100, Andre Klapper a écrit : Am Donnerstag, den 08.01.2009, 16:14 +0100 schrieb Stéphane Raimbault: Fixed on trunk. We need a mailing list to talk about Damned-Lies :) gnome-i18n-devel-list exists but it has never been used. ;-) I suspect this list may be more for i18n issues in GNOME development in general. But now these things are discussed in gtk-i18n-list. So if it is not used, it could be recycled for damned-lies :-) Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: New release of Damned Lies with Vertimus included
Le jeudi 08 janvier 2009 à 16:41 +0100, Matej Urbančič a écrit : Just trying to understand ... So, can I also change the faulty info on the http://l10n.gnome.org/teams/ and http://l10n.gnome.org/languages/sl/ ? Web page link is corrupt. No, Team infos require a GTP coordinator to modify it in the admin interface. Just ping someone on #i18n or open a bug report. Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Wrong 'action' dates on l10n.gnome.org
Le jeudi 08 janvier 2009 à 14:18 +0100, Luca Ferretti a écrit : snip About this topic, may I also propose two enhancements? * add the ability to localize dates/times and/or allow them to be user configurable. If you access to page [1] using en as browser language, you have: state date using English (WW DD MM YY HH:MM AM/PM) format; POT file update date using UTC, actions dates using local times. IMHO those dates/times should all use the same format, specified in damned-lies PO or chosen by single user. * add the ability to sort summaries (users and releases) by dates. Example: go to Italian summary for GNOME 2.26 release[2] (note by now we are just experimenting/testing with new l10n.g.o, only few modules have a state). Modules are listed in alphabetical order. From a coordinator point of view, could be good sort them by state-date, in order to check and poke people that claimed a translation for a long time and never uploaded it. Cheers, Luca. [1] http://l10n.gnome.org/vertimus/367/345/82 [2] http://l10n.gnome.org/languages/it/gnome-2-26/ui/ Can you please open bugzilla reports for this two proposals? Thanks. Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
String changes to gnome-keyring
I've committed string changes to gnome-keyring in the following file: daemon/pkcs11/gkr-pkcs11-auth.c Cheers, Stef Walter ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Wrong 'action' dates on l10n.gnome.org
Il giorno gio, 08/01/2009 alle 20.11 +0100, Claude Paroz ha scritto: Le jeudi 08 janvier 2009 à 14:18 +0100, Luca Ferretti a écrit : Can you please open bugzilla reports for this two proposals? Done, see http://bugzilla.gnome.org/show_bug.cgi?id=567080 Use an unique format for dates (maybe configurable) http://bugzilla.gnome.org/show_bug.cgi?id=567084 Add the ability to sort summary pages by dates ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Wrong 'action' dates on l10n.gnome.org
Le jeudi 08 janvier 2009 à 22:38 +0100, Luca Ferretti a écrit : Il giorno gio, 08/01/2009 alle 20.11 +0100, Claude Paroz ha scritto: Le jeudi 08 janvier 2009 à 14:18 +0100, Luca Ferretti a écrit : Can you please open bugzilla reports for this two proposals? Done, see http://bugzilla.gnome.org/show_bug.cgi?id=567080 Use an unique format for dates (maybe configurable) http://bugzilla.gnome.org/show_bug.cgi?id=567084 Add the ability to sort summary pages by dates Great! We'll try our best to not let them rot :-P Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
How to translate GTK+ 2.16 (trunk)
Moving to msgctxt [1] created approx. 300 fuzzy messages in GTK+. The GNU Gettext doesn't know about our old context hack, so when Damned Lies merged the old translations with the new POT file, most translations with context were marked as fuzzy and/or lost. This is a suggestion on how to reuse the translations in GTK+ 2.14 (from GNOME 2.24) with minimal need for manual work. This will work well only if you didn't start to translate GTK+ trunk yet. Start downloading gtk+.HEAD.ab_CD.po (I'll call it new.po for short) and gtk+.gtk-2-14.ab_CD.po (old.po). Then run: sed -i s+msgid \\([^|]*\)|+msgctxt \\1\\nmsgid \+ old.po msgmerge -U old.po new.po Now, you should be able to finish translating old.po and upload it to Damned Lies as the new translation for GTK+ trunk. It worked well for me, and I hope it works for everyone in the same situation. If something looks weird or if the commands look like greek for you (no offense meant ;) ) then please check the content of old.po after every step: open it with a text editor, run msgfmt -cvo /dev/null old.po or open it with you favorite translation tool. 1. http://live.gnome.org/GnomeGoals/MsgctxtMigration -- Leonardo Fontenelle http://leonardof.org ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
On Tue, 2009-01-06 at 15:24 +, Simos Xenitellis wrote: The GNOME dev discussion takes place at http://mail.gnome.org/archives/desktop-devel-list/2009-January/thread.html#3 The discussion is somewhat heated, so it's no place for translators to post about. The real discussion about how the migration is being done is in gnome-infrastructure: http://mail.gnome.org/archives/gnome-infrastructure/2009-January/thread.html And our scratchpad is here: http://live.gnome.org/GitMigration If a move eventually takes place, it will require time and effort, so it would not happen within the next six months. We hope to have working repositories, at least for guinea pigs, within two weeks :) Moving all the repositories over to git will of course require time --- it's not the conversion that is the biggest problem, but fixing the infrastructure and writing documentation. The big question is, how would a DVCS affect the GNOME localisation workflows? One of my tasks for the migration to Git is to write a little bunch of tutorials for various scenarios --- maintainers, contributors, translators, etc. However, I'm not 100% sure about the workflows that translators tend to use. Do people mostly use web tools (and what happens then --- does the tool commit for them)? Or do they checkout a whole module and simply commit to the .po files? Or do they checkout a *single* .po file and then commit it back, or send patches to a language coordinator? Federico ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
Em Qui, 2009-01-08 às 18:19 -0600, Federico Mena Quintero escreveu: The real discussion about how the migration is being done is in gnome-infrastructure: http://mail.gnome.org/archives/gnome-infrastructure/2009-January/thread.html Thanks for clarifying this. However, I'm not 100% sure about the workflows that translators tend to use. Do people mostly use web tools (and what happens then --- does the tool commit for them)? Or do they checkout a whole module and simply commit to the .po files? Or do they checkout a *single* .po file and then commit it back, or send patches to a language coordinator? Currently translations must be committed by translator with svn access. Adding committing capabilities in Damned Lies is somewhat in the roadmap, but currently the developers are implementing more basic features, like team management. As a translator, I just have to check out the po/ or help/ subdirs where I want to commit my translation files to. There's even a LINGUAS file in the po/ subdirs to avoid translators checking out the whole module just to edit Makefile.am. AFAIK moving to git would mean committers must checkout the whole module. If it can't be worked around, it will be a major problem for most translation teams. Brazil is not exactly a poor country, and 128kbps is still called broadband here. -- Leonardo Fontenelle http://leonardof.org ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
Leonardo F. Fontenelle wrote: As a translator, I just have to check out the po/ or help/ subdirs where I want to commit my translation files to. There's even a LINGUAS file in the po/ subdirs to avoid translators checking out the whole module just to edit Makefile.am. The main reason to move to LINGUAS was in fact to make it less error prune for translators. Previously we were left with many broken builds because, eg, the editor decided to break the line and the translator (not exactly savvy in configure.ac syntax) didn't notice. AFAIK moving to git would mean committers must checkout the whole module. That's assuming that the transition team does not find a solution to this problem. Lets not speculate and focus on the problems that need to be solved. That's why Federico is here asking you what your workflow is. If the transition happens and you are left in the cold having to download the full module to commit one file, you have all rights to complain :). Cheers, behdad If it can't be worked around, it will be a major problem for most translation teams. Brazil is not exactly a poor country, and 128kbps is still called broadband here. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
msgctxt migration
I tried to help with the msgctxt migration, but then I found out I have no idea on how to migrate Python source code to use msgctxt. Please, if anyone knows how to, please add the information here: http://live.gnome.org/GnomeGoals/MsgctxtMigration -- Leonardo Fontenelle http://leonardof.org ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
У чет, 08. 01 2009. у 18:19 -0600, Federico Mena Quintero пише: However, I'm not 100% sure about the workflows that translators tend to use. Usually every team has a few people who are commiters (including team coordinator). People that just want to do translation, they tend to download updated PO file from Damned Lies (http://l10n.gnome.org) and send it to project mailing list, coordinator or one of trusted commiters. Now it's possible to send it to commiters via Damned Lies too. There are also people that want to peek inside sources while translating or they want to test translations by building and running applications so they like to checkout complete module. No difference from any other here. Somebody said in this thread that there are people that want to fetch just po subdir. The only scenario I can came up with is that there are commiters with slow Internet access... In any case they must download PO file from Damned Lies as source is needed to update file with new messages. Translators who don't need complete source can download tarball with all PO files from Damned Lies. Review process is important inside workflow, and I think that every team has its own best practice according to team size and resources, but I don't believe it is different than translating from a perspective of version control. And everybody need revisions (even broken ones with non-aligned PO files are better than none). Those without sources can use viewvc interface. After getting two versions (by download or checkout), one must align two PO files with msgcat tool before doing diff. (Get revision from last review, align it with trunk and then compare in diff-tool like meld to review changes and fix errors, for example) Inside string freeze some modules branch early for release and commiters need to commit translation both to string-frozen branch and later to trunk (I like to do this immediately not to forget later). Once again, there is noting translation-specific inside. For large teams, it may prove (I'm just guessing, Serbian team is small) useful to have one repository for all PO files, grouped by language so translators, editors, commiters and coordinator can all work in a distributed environment without cloning everything else. This would in addition solve repository-size issue too, and those wanting sources can get them too. KDE is using this approach. It is important to note that not having this will NOT be a drawback from current svn-based solution and we can always think about it in the future. -- Goran ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
On Fri, Jan 9, 2009 at 12:19 AM, Federico Mena Quintero feder...@ximian.com wrote: On Tue, 2009-01-06 at 15:24 +, Simos Xenitellis wrote: The GNOME dev discussion takes place at http://mail.gnome.org/archives/desktop-devel-list/2009-January/thread.html#3 The discussion is somewhat heated, so it's no place for translators to post about. The real discussion about how the migration is being done is in gnome-infrastructure: http://mail.gnome.org/archives/gnome-infrastructure/2009-January/thread.html And our scratchpad is here: http://live.gnome.org/GitMigration If a move eventually takes place, it will require time and effort, so it would not happen within the next six months. We hope to have working repositories, at least for guinea pigs, within two weeks :) Moving all the repositories over to git will of course require time --- it's not the conversion that is the biggest problem, but fixing the infrastructure and writing documentation. The big question is, how would a DVCS affect the GNOME localisation workflows? One of my tasks for the migration to Git is to write a little bunch of tutorials for various scenarios --- maintainers, contributors, translators, etc. However, I'm not 100% sure about the workflows that translators tend to use. Do people mostly use web tools (and what happens then --- does the tool commit for them)? Or do they checkout a whole module and simply commit to the .po files? Or do they checkout a *single* .po file and then commit it back, or send patches to a language coordinator? Currently, the web tools do not commit translations for the translators in GNOME i18n. Thus, what translators with SVN access do is 1. Checking out a full module and committing the translation (after running 'intltool-update LL', which updates the translation to the latest version of the code) 2. Checking out just the po/ subdirectory and committing the translation. It is not common to send patches of PO files for committing because the reference files provided from damned-lies may change at any time when new translation strings are added. The Translation Project (http://translationproject.org/) has (for many years now) an automated system where you send the translation file as an e-mail attachment and it adds it for you to a common location of translation files. Something that would be desirable with GNOME translations would be to able to make easily changes across all the translations of a language, and then commit the files in an easy way. In KDE, all translations for a specific language reside in a separate directory tree, which makes it easy to make overall changes. I think the KBabel/Lokalize tool has an option to allow to view all the translations in a single list, so that one can identify discrepancies in similar terms. The same tool has an option to commit (SVN) the translations from within the GUI. Reading about 'git submodule' at http://book.git-scm.com/5_submodules.html it looks it might be good to try this feature in order to separate the translations from the code in each repository. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
