Re: palimpsest translate?
Le jeudi 16 avril 2009 à 14:25 -0400, David Zeuthen a écrit : Hey, On Mon, 2009-04-13 at 17:13 +0200, Christian Rose wrote: On 4/13/09, Benjamín Valero Espinosa benjaval...@gmail.com wrote: 2009/4/10 Piotr Drąg piotrd...@gmail.com Thomas Spura pisze: It seems this is the program gnome-disk-utility. I don't find a link to this project... http://cgit.freedesktop.org/users/david/gnome-disk-utility/ only says 'no repos found'... It currently lives at [1]. I think that it will be translated by GNOME Translation Project, so don't worry. :) [1] http://git.gnome.org/cgit/gnome-disk-utility Well, I cannot find that module to be translated: http://l10n.gnome.org/module/ It seems the module was never announced to the GNOME Translation Project, so as a consequence no l10n.gnome.org page was ever added. I've fixed that now: http://l10n.gnome.org/module/gnome-disk-utility/ I'm also cc:ing the maintainer. Great, thanks, I've been wanting to ask for translations as gnome-disk-utility will be used by GVfs in the GNOME 2.28 release (we are using in Fedora 11 already); in particular strings for drives, volumes and mounts will come from gnome-disk-utility. Now, gnome-disk-utility actually has quite a lot of strings marked for translation and I wanted to talk to you guys about that. - src/gdu/gdu-ata-smart-attribute.c These are names and descriptions of ATA SMART attributes; not sure we can't get around to not translating them; they appear in the UI for inspecting a hard disk, e.g. http://people.freedesktop.org/~david/gdu-smart.png (note, the UI is not very pretty right now.. but I do expect us to list all attributes including localized names and descriptions) - src/gdu/gdu-util.c All the various MS-DOS partition types (and there is a lot of these) are marked for translation. For example - Hidden FAT16 32M (0x14) - PartitionMagic (0x3c) Maybe we don't really want this, I mean these are more names than anything so maybe we it shouldn't be marked for translation. Or maybe translators can just decide not to translate it. Maybe I can just add Translator: comments for that. Thoughts? Thanks for any insights. Hi David, I think the current choices are right, even if it will be tough work for translators. Even if many strings might be kept as original, some will not (e.g. Hidden FAT16 might be translated to FAT16 cachée in French). And yes, it would be useful for translators to have the information URLs you have in the source code as translator comments (put them in the first occurrence of their respective category). I think it's already the case in gdu-util.c. Claude -- www.2xlibre.net ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Adding mistelix to translation pages
Hello, I request please if you can add the project Mistelix to the translations status page. The code is here: http://git.gnome.org/cgit/mistelix/ Thanks, [1] http://www.mistelix.org -- Jordi Mas i Hernàndez. Bloc: http://gent.softcatala.org/jmas/bloc/ Planet Softcatalà - http://planeta.softcatala.org ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Do you like the ChangeLog
Hi! We decided to remove the ChangeLog for source code changes on the anjuta and the gdl module and use git log instead. Do translaters prefer to keep po/ChangeLog or not? Thanks, Johannes signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Do you like the ChangeLog
Le vendredi 17 avril 2009 à 10:34 +0200, Johannes Schmid a écrit : Hi! We decided to remove the ChangeLog for source code changes on the anjuta and the gdl module and use git log instead. Do translaters prefer to keep po/ChangeLog or not? No, as it seems the majority of modules will drop the ChangeLog, translators will too. This is one of the few advantages of the migration for translators, let's take advantage of it :-) IMHO, ChangeLog files for po directories were useless (except maybe for POTFILES.* changes). Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
String additions to 'deskbar-applet.master'
This is an automatic notification from status generation scripts on: http://l10n.gnome.org. There have been following string additions to module 'deskbar-applet.master': + bAvailable Extensions/b + bChoose the language the results should be in:/b + bExtensions with Errors/b + bLoaded Extensions/b + bWindow Behavior/b + bigbLogin for %s/b/big + bigbLogin to %s rejected/b/big + ismallDrag and drop an extension to change its order./small/i + iEmpty history/i + iEmpty/i + small(%(remain)s)/small Post i\%(msg)s\/i + A file named \%s\ already exists. Do you want to replace it? + A list of available extensions is downloaded. + A post is already awaiting submission, please wait before you post another message + A problem occured + About + Add OpenSearch Website + Additional results for category b%s/b + All Extensions + An all-in-one action bar + Arabic + As you type, Wikipedia will offer suggestions. + Audio + Autocompletion Needs to be Enabled\nWe cannot provide e-mail addresses from your address book unless autocompletion is enabled. To do this, from your mail program's menu, choose Edit - Preferences, and then Autocompletion. + Back to Matches + Beagle daemon is not running. + Beagle does not seem to be installed. + Beagled could not be found in your $PATH. + Bulgarian + Calculate simple equations + Calculator + Cannot execute program: + Cannot show URL: + Catalan + Check the description beneath for further details. + Chinese simplified + Chinese traditional + Chinese + Choose Folder + Choose the language you want to use or enter the code of your language manually + Choose whether triggering the keyboard shortcut also pastes the current selection in the search box. + Clear History + Clear entry after match has been selected + Collapsed categories + Configure Google + Configure Yahoo! + Contents + Copy b%(name)s/b to clipboard + Copy b%(origtext)s = %(name)s/b to clipboard + Could not load beagle, libbeagle has been compiled without python bindings. + Create %s + Create Document + Create new files from your templates + Create note b%(name)s/b + Credentials for %s + Croatian + Czech + Danish + Delete note b%(name)s/b + Description missing + Deskbar Applet + Details + Devhelp is not installed + Display additional actions + Display extensions with tag: + Downloading extension + Dutch + Edit OpenSearch Website + Edit contact b%(name)s/b (%(email)s) + Enabled handlers + English + Enter the location (URL) of the OpenSearch description document for this website. The name and description can be loaded automatically from this document or you can just enter your own values manually. + Epiphany is not your preferred browser. + Error posting to %s + Error + Estonian + Execute %s in terminal + Extension could not be installed due to a problem with the provided file + Extension has been installed successfully + Extensions with Errors + Extracting archive + Failed to post update to %(domain)s.\nPlease make sure that:\n\n • Your internet connection is working\n • You can connect to ihttp://%(domain)s/i in\nyour web browser\n • Your credentials in the preferences are correct + Finnish + Firefox version must be at least %s and less than %s + Folder: + French + From i%s/i + GNOME dictionary is not installed + GNOME search tool is not installed + General + German + Go to location of %s + Google Code Search + Google Search + Greek + Hebrew + Help + Hibernate this system now? + Hungarian + Icelandic + If enabled it will clear the entry after a search result has been selected + If enabled the window will be closed after an action has been activated + If you delete a note it is permanently lost. + Images + Indonesian + Installing extension + Italian + Japanese + Keybinding + Korean + Latvian + Lithuanian + Location missing + Location + Log out of this system now? + Make sure the URL points to a valid OpenSearch description document. + Milliseconds to wait before starting to search + Minimum number of characters needed to start searching + Mozilla/Firefox is not your preferred browser. + Name missing + Name: + New Extensions + Norwegian + Open %s containing %s + Open b%(name)s/b with b%(program)s/b + Open article i%(name)s/i in bWikipedia/b + Open note b%(name)s/b + Open package i%(name)s/i + OpenSearch Settings + OpenSearch + Password: + Persian + Please enter a description for this website + Please enter a name for this website + Please enter a valid location (URL) for this website +
Re: Do you like the ChangeLog
On Fri, Apr 17, 2009 at 10:43:19AM +0200, Claude Paroz wrote: Le vendredi 17 avril 2009 ?? 10:34 +0200, Johannes Schmid a ??crit : Hi! We decided to remove the ChangeLog for source code changes on the anjuta and the gdl module and use git log instead. Do translaters prefer to keep po/ChangeLog or not? No, as it seems the majority of modules will drop the ChangeLog, translators will too. This is one of the few advantages of the migration for translators, let's take advantage of it :-) IMHO, ChangeLog files for po directories were useless (except maybe for POTFILES.* changes). I don't think these were useless, afair the maintainer.py script parses the ChangeLog besides the last-translator: field to ensure that all translators between two releases get credit and not only the last one. But I guess the script can be fixed. Same for the traslator tools. Claudio Claude ___ 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
git: using branches
Hi all! I tried to follow the Git translators guide[1] to update the anjuta translation (which is already branched). So I git clone it and then I tried to switch to the gnome-2-26 branch but failed with the git checkout --track origin/gnome-2-26 command. After some research I finally found something that works: git checkout -b local-gnome-2-26 origin/gnome-2-26 With this, git creates a local branch named local-gnome-2-26 from origin/gnome-2-26 remote branch. Then edit files, git commit and git push as usual. I have git 1.6.0.6, don't know if it has changed with previous or newer versions. Should I update the working with branches section with this commands? Cheers, [1] http://live.gnome.org/GitMigration/Translators -- gil forcada [ca] guifi.net - una xarxa lliure que no para de créixer [en] guifi.net - a non-stopping free network bloc: http://gil.badall.net ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
String additions to 'sabayon.gnome-2-24'
This is an automatic notification from status generation scripts on: http://l10n.gnome.org. There have been following string additions to module 'sabayon.gnome-2-24': + No search base specified for %s + Remove personal information from documents when saving them Note that this doesn't directly indicate a string freeze break, but it might be worth investigating. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Do you like the ChangeLog
On Fri, Apr 17, 2009 at 10:43, Claude Paroz cla...@2xlibre.net wrote: Le vendredi 17 avril 2009 à 10:34 +0200, Johannes Schmid a écrit : Hi! We decided to remove the ChangeLog for source code changes on the anjuta and the gdl module and use git log instead. Do translaters prefer to keep po/ChangeLog or not? No, as it seems the majority of modules will drop the ChangeLog, translators will too. This is one of the few advantages of the migration for translators, let's take advantage of it :-) IMHO, ChangeLog files for po directories were useless (except maybe for POTFILES.* changes). Honestly, I would rather have ChangeLog in every single module, or do not have it at all. Mixtures are bad since many translators have scripts to update translations or use built-in tools such as kbabel or gtranslator. Cheers. -- alor...@gmail.com http://aloriel.no-ip.org IM: alor...@jabber.org ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
On Fri, Apr 17, 2009 at 12:59 PM, Gil Forcada gforc...@gnome.org wrote: Hi all! I tried to follow the Git translators guide[1] to update the anjuta translation (which is already branched). So I git clone it and then I tried to switch to the gnome-2-26 branch but failed with the git checkout --track origin/gnome-2-26 command. After some research I finally found something that works: git checkout -b local-gnome-2-26 origin/gnome-2-26 With this, git creates a local branch named local-gnome-2-26 from origin/gnome-2-26 remote branch. Then edit files, git commit and git push as usual. I have git 1.6.0.6, don't know if it has changed with previous or newer versions. Should I update the working with branches section with this commands? Thanks for catching this (-b 'branch'). Feel free to update the Wiki page. Just a note, the page has been moved to http://live.gnome.org/TranslationProject/GitHowTo Cheers, Simos Cheers, [1] http://live.gnome.org/GitMigration/Translators -- gil forcada [ca] guifi.net - una xarxa lliure que no para de créixer [en] guifi.net - a non-stopping free network bloc: http://gil.badall.net ___ 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: git: using branches
I hope so too, but my small research ended up with this that at least works by now :) Cheers, El dv 17 de 04 de 2009 a les 14:23 +0200, en/na Luca Ferretti va escriure: 2009/4/17 Gil Forcada gforc...@gnome.org: Should I update the working with branches section with this commands? I hope there is a more simple way to do this. This seems a nonsense to me: create a new local branch in order to commit+push on an existing branch on server... BTW there is no way to produce a ligthweight local copy? I.e. only the latest versione of a single branch, instead full history form all branches for a given module. Could be good for simple commits like like this, waiting for commit support in damned-lies. -- gil forcada [ca] guifi.net - una xarxa lliure que no para de créixer [en] guifi.net - a non-stopping free network bloc: http://gil.badall.net ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
On Fri, Apr 17, 2009 at 1:23 PM, Luca Ferretti elle@libero.it wrote: 2009/4/17 Gil Forcada gforc...@gnome.org: Should I update the working with branches section with this commands? I hope there is a more simple way to do this. This seems a nonsense to me: create a new local branch in order to commit+push on an existing branch on server... BTW there is no way to produce a ligthweight local copy? I.e. only the latest versione of a single branch, instead full history form all branches for a given module. Could be good for simple commits like like this, waiting for commit support in damned-lies. We have mentioned these some time ago. Search for 'shallow' clones. It's the '--depth' parameter in 'git clone'. My personal view is that a shallow clone (that is, a clone with limited history) provides small gains. More comments and benchmarking on this would be welcome. I think that it is better to get full clones of the GNOME release repositories and simply keep them locally, and update (with git pull --rebase) before committing. My view is to propose to the GNOME translators to dedicate around 2GB for permanent local GNOME repositories, for those that wish to keep using the command line. I plan to update my script at http://github.com/simos/intltool-manage-vcs/tree once git.gnome.org stabilises, so that you can simply let it run and it gets the repos for you. Another option would be to have anonymous git repository tarballs, so that you can wget in one go (or have then sent by DVD), then extract and use a git command to convert from anonymous to repositories with your account details. This would require some talk at gnome-infrastructure to see if the benefits are enough to put this in place. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
Simos Xenitellis ha scritto: We have mentioned these some time ago. Search for 'shallow' clones. It's the '--depth' parameter in 'git clone'. My personal view is that a shallow clone (that is, a clone with limited history) provides small gains. More comments and benchmarking on this would be welcome. git clone help says also that you cannot push after cloning with a --depth option, whereas Git for GNOME translators says it's (almost?) OK: has it been tested? I'm not keen on being a guinea-pig for this... :) I'm not really interested in ten years of repository history for pushing a couple of files, plus add to that if I also have to locally clone the repository... I think that it is better to get full clones of the GNOME release repositories and simply keep them locally, and update (with git pull --rebase) before committing. What is the status of damned-lies commit-upload of translations? This, from my POV, would be the best solution. Cheers. -- Milo Casagrande m...@casagrande.name ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
String additions to 'gnome-backgrounds.gnome-2-22'
This is an automatic notification from status generation scripts on: http://l10n.gnome.org. There have been following string additions to module 'gnome-backgrounds.gnome-2-22': + Aqua + Blinds + Dune + Flow + Garden + Gulp + Lady Bird + Rain Drops + Silk + Spring + Storm Note that this doesn't directly indicate a string freeze break, but it might be worth investigating. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
2009/4/17 Luca Ferretti elle@libero.it: 2009/4/17 Gil Forcada gforc...@gnome.org: Should I update the working with branches section with this commands? I hope there is a more simple way to do this. This seems a nonsense to me: create a new local branch in order to commit+push on an existing branch on server... Uh, so assuming this comment is in reference to the way SVN works, how did you commit to a branch without creating a local working copy in SVN? SVN: svn co url-to-branch svn commit Git: git checkout --track -b mybranch origin/somebranch git commit git push It's not like those really differ in other ways than in that with git you only keep a single working copy at any given time... -- Kalle Vahlman, z...@iki.fi Powered by http://movial.com Interesting stuff at http://sandbox.movial.com See also http://syslog.movial.fi ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
String additions to 'libgweather.master'
This is an automatic notification from status generation scripts on: http://l10n.gnome.org. There have been following string additions to module 'libgweather.master': + %.1f °C + %.1f °F + %d °C + %d °F Note that this doesn't directly indicate a string freeze break, but it might be worth investigating. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
Simos Xenitellis ha scritto: In practice the space difference is not significant. We should be able to have real statistics on this soon, so that we can have a proper guideline on shallow clones. That would be interesting, at least to have an idea of what to expect. AFAIK, the standing issue is the creation of a generic account that damned-lies will use when committing on behalf of the translators. I asked 'cause I hoped something had changed in that front since last time... There Accounts team is understaffed and several requests take long to be fulfilled. There was a call for volunteers recently and actually it would be great to have a GNOME translator on this team to push forward the translator requests. I would be happy to lend a hand... how is that suppose to work? -- Milo Casagrande m...@casagrande.name ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Damned-lies typo
Hi, I found a typo: msgid This is a clone of the official version from the freedektop repository It should be freedesktop :) Cheers, -- gil forcada [ca] guifi.net - una xarxa lliure que no para de créixer [en] guifi.net - a non-stopping free network bloc: http://gil.badall.net ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
String additions to 'gucharmap.gnome-2-22'
This is an automatic notification from status generation scripts on: http://l10n.gnome.org. There have been following string additions to module 'gucharmap.gnome-2-22': + You should have received a copy of the GNU General Public License along with Gucharmap; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02110-1301 USA Note that this doesn't directly indicate a string freeze break, but it might be worth investigating. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Damned-lies typo
Le vendredi 17 avril 2009 à 17:06 +0200, Gil Forcada a écrit : Hi, I found a typo: msgid This is a clone of the official version from the freedektop repository It should be freedesktop :) Gil, feel free to correct it yourself in the admin interface. Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Damned-lies typo
Hi! Gil Forcada gforc...@gnome.org, Fri, 17 Apr 2009 17:06:54 +0200: Hi, I found a typo: msgid This is a clone of the official version from the freedektop repository It should be freedesktop :) freedesktop.org, preferably. ;-) Best, Petr Kovar ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
On Fri, Apr 17, 2009 at 3:51 PM, Milo Casagrande m...@casagrande.name wrote: Simos Xenitellis ha scritto: In practice the space difference is not significant. We should be able to have real statistics on this soon, so that we can have a proper guideline on shallow clones. That would be interesting, at least to have an idea of what to expect. AFAIK, the standing issue is the creation of a generic account that damned-lies will use when committing on behalf of the translators. I asked 'cause I hoped something had changed in that front since last time... There Accounts team is understaffed and several requests take long to be fulfilled. There was a call for volunteers recently and actually it would be great to have a GNOME translator on this team to push forward the translator requests. I would be happy to lend a hand... how is that suppose to work? Have a look at http://live.gnome.org/AccountsTeam There was a call on planet.gnome.org recently, however I think it replicated the information you can find on the accounts team. Thanks, Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
String additions to 'sound-juicer.gnome-2-20'
This is an automatic notification from status generation scripts on: http://l10n.gnome.org. There have been following string additions to module 'sound-juicer.gnome-2-20': + Overwrite _All + S_kip All Note that this doesn't directly indicate a string freeze break, but it might be worth investigating. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
2009/4/17 Kalle Vahlman kalle.vahl...@gmail.com: 2009/4/17 Luca Ferretti elle@libero.it: I hope there is a more simple way to do this. This seems a nonsense to me: create a new local branch in order to commit+push on an existing branch on server... Uh, so assuming this comment is in reference to the way SVN works, how did you commit to a branch without creating a local working copy in SVN? Oh, no, my comment was in reference to the way MY MIND works ;) I mean, my mind expects something like those (fake) commands: $ dcvs clone module $ cd module $ dvcs where-i-am branch: master $ dvcs switch revision-2-26 $ dvcs where-i-am branch: revision-2-26 In my mind a new local branch should be creaed only if you plan to work on a large feature, not just to commit a small change or existing patch. But of course this is my own vision of DVCS. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
On Fri, Apr 17, 2009 at 8:55 PM, Luca Ferretti elle@libero.it wrote: 2009/4/17 Kalle Vahlman kalle.vahl...@gmail.com: 2009/4/17 Luca Ferretti elle@libero.it: I hope there is a more simple way to do this. This seems a nonsense to me: create a new local branch in order to commit+push on an existing branch on server... Uh, so assuming this comment is in reference to the way SVN works, how did you commit to a branch without creating a local working copy in SVN? Oh, no, my comment was in reference to the way MY MIND works ;) I mean, my mind expects something like those (fake) commands: $ dcvs clone module $ cd module $ dvcs where-i-am branch: master $ dvcs switch revision-2-26 $ dvcs where-i-am branch: revision-2-26 In my mind a new local branch should be creaed only if you plan to work on a large feature, not just to commit a small change or existing patch. But of course this is my own vision of DVCS. When you 'git checkout' another branch, you perform an offline process. All the relevant information is already in the history, locally. Regarding the issue of having to specify the 'local branch name', I suppose there must be some story behind the question 'Why do we specify the branch name instead of reusing the remote branch name by default? It feels somewhat weird.'. With a big more experience we should be able to figure it out. In any case, any issues that come up, albeit simple, should be discussed so that we add it to the Git HowTo page on live.gnome.org, http://live.gnome.org/TranslationProject/GitHowTo Usability issues are very important too. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: palimpsest translate?
2009/4/13 Christian Rose It seems the module was never announced to the GNOME Translation Project, so as a consequence no l10n.gnome.org page was ever added. I've fixed that now: http://l10n.gnome.org/module/gnome-disk-utility/ I'm also cc:ing the maintainer. I just can see the PO for the manual, not for the UI, so by now there's not too much to translate. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Git migration and 2.28
Hi, l10n.gnome.org is now up-to-date regarding the git migration, excepting the famous seahorse-plugins module. http://bugzilla.gnome.org/show_bug.cgi?id=563474 I've also created the gnome-2-28 release set. Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Missing gnote in l10n.gnome.org modules
As per summary, could someone add this to list? Thanks. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Do you like the ChangeLog
Le vendredi 17 avril 2009 à 11:13 +0200, Jorge González a écrit : On Fri, Apr 17, 2009 at 10:43, Claude Paroz cla...@2xlibre.net wrote: Le vendredi 17 avril 2009 à 10:34 +0200, Johannes Schmid a écrit : Hi! We decided to remove the ChangeLog for source code changes on the anjuta and the gdl module and use git log instead. Do translaters prefer to keep po/ChangeLog or not? No, as it seems the majority of modules will drop the ChangeLog, translators will too. This is one of the few advantages of the migration for translators, let's take advantage of it :-) IMHO, ChangeLog files for po directories were useless (except maybe for POTFILES.* changes). Honestly, I would rather have ChangeLog in every single module, or do not have it at all. Mixtures are bad since many translators have scripts to update translations or use built-in tools such as kbabel or gtranslator. No more ChangeLogs, that's the new rule, at least for translators. Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
On Fri, Apr 17, 2009 at 3:09 PM, Simos Xenitellis simos.li...@googlemail.com wrote: I suppose there must be some story behind the question 'Why do we specify the branch name instead of reusing the remote branch name by default? It feels somewhat weird.'. With a big more experience we should be able to figure it out. For ease of use, DO NOT use a different local branch name. It will cause 'git push origin local-branch-name' (without other args) to create a new branch on the remote side named after your local branch. This is not what you want (and then you have to find someone to delete your mistake). If you name the local branch exactly the same as the remote tracking branch, 'git push' will just magically work correctly. So ALWAYS do: $ git checkout -b remotename origin/remotename ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
On Fri, Apr 17, 2009 at 10:21 PM, Jason D. Clinton m...@jasonclinton.com wrote: On Fri, Apr 17, 2009 at 3:09 PM, Simos Xenitellis simos.li...@googlemail.com wrote: I suppose there must be some story behind the question 'Why do we specify the branch name instead of reusing the remote branch name by default? It feels somewhat weird.'. With a big more experience we should be able to figure it out. For ease of use, DO NOT use a different local branch name. It will cause 'git push origin local-branch-name' (without other args) to create a new branch on the remote side named after your local branch. This is not what you want (and then you have to find someone to delete your mistake). If you name the local branch exactly the same as the remote tracking branch, 'git push' will just magically work correctly. So ALWAYS do: $ git checkout -b remotename origin/remotename Is the '--track' parameter required when using 'git checkout'? Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Git migration and 2.28
On Fri, Apr 17, 2009 at 9:42 PM, Claude Paroz cla...@2xlibre.net wrote: Hi, l10n.gnome.org is now up-to-date regarding the git migration, excepting the famous seahorse-plugins module. http://bugzilla.gnome.org/show_bug.cgi?id=563474 I've also created the gnome-2-28 release set. Thanks Claude! I noticed that after the migration to git, GNOME 2.26/Documentation shows 55% instead of 60% that was before. Could that be a package that translations got lost during the migration? Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
On Fri, Apr 17, 2009 at 4:29 PM, Simos Xenitellis simos.li...@googlemail.com wrote: Is the '--track' parameter required when using 'git checkout'? My git-config manpage says its on by default and it has been that way for as long as I've been using git. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Missing gnote in l10n.gnome.org modules
On 4/17/09, Luca Ferretti elle@libero.it wrote: As per summary, could someone add this to list? Cryptic mail; took me a few seconds to figure out. Added now: http://l10n.gnome.org/module/gnote/ Christian ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
On 4/17/09, Simos Xenitellis simos.li...@googlemail.com wrote: [...] There Accounts team is understaffed and several requests take long to be fulfilled. In general, only those with missing/erroneous/incorrectly filled in data. Or requests regarding teams with coordinators that forgot their Mango passwords (http://live.gnome.org/MangoFAQ). A correctly filled in Mango account request, for a team where the team coordinator remembers their Mango password, should not take more than 1-2 weeks to resolve, at the most. Mostly because I only have time to do GNOME work on spare time on weekends :-( There was a call for volunteers recently and actually it would be great to have a GNOME translator on this team to push forward the translator requests. Don't I count? But more help is very welcome. I started out helping with accounts many years ago because I wanted to do exactly that; help resolve as many translator account requests in a speedy manner as I could. Nowadays, there's essentially just me doing almost *all* account work for all of GNOME. :-( Christian ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
On Fri, Apr 17, 2009 at 11:28 PM, Christian Rose ment...@gnome.org wrote: On 4/17/09, Simos Xenitellis simos.li...@googlemail.com wrote: [...] There Accounts team is understaffed and several requests take long to be fulfilled. In general, only those with missing/erroneous/incorrectly filled in data. Or requests regarding teams with coordinators that forgot their Mango passwords (http://live.gnome.org/MangoFAQ). A correctly filled in Mango account request, for a team where the team coordinator remembers their Mango password, should not take more than 1-2 weeks to resolve, at the most. Mostly because I only have time to do GNOME work on spare time on weekends :-( There was a call for volunteers recently and actually it would be great to have a GNOME translator on this team to push forward the translator requests. Don't I count? Sorry, I did not notice you in the Account Team list! But more help is very welcome. I started out helping with accounts many years ago because I wanted to do exactly that; help resolve as many translator account requests in a speedy manner as I could. Nowadays, there's essentially just me doing almost *all* account work for all of GNOME. :-( I'ld be happy to apply as well. I am e-mailing AccountsTeam. Cheers, Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
On Fri, Apr 17, 2009 at 10:41 PM, Jason D. Clinton m...@jasonclinton.com wrote: On Fri, Apr 17, 2009 at 4:29 PM, Simos Xenitellis simos.li...@googlemail.com wrote: Is the '--track' parameter required when using 'git checkout'? My git-config manpage says its on by default and it has been that way for as long as I've been using git. The issue about --track and -b _branchname_ is a bug in Git, http://kerneltrap.org/mailarchive/git/2008/10/19/3723354 So, with old/all git versions, $ git checkout -b composer-dev origin/composer-dev Branch composer-dev set up to track remote branch refs/remotes/origin/composer-dev. Switched to a new branch 'composer-dev' $ _ With old git versions, if you try to omit -b branch, you get $ git checkout --track origin/compose-dev fatal: git checkout: --track and --no-track require -b $ _ With newer git version, $ git checkout --track origin/composer-dev Branch composer-dev set up to track remote branch refs/remotes/origin/composer-dev. Switched to a new branch 'composer-dev' $ _ So, if you have the latest version of git, you do not need to specify the local branch in the command line. I think the new system looks cleaner and less error-prone. For now, we keep the old syntax at live.gnome.org. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Adding WebKitGTK+ to the translation stats pages
On Thu, 16 Apr 2009 16:14:41 -0300, Gustavo Noronha Silva gustavo.noro...@collabora.co.uk said: On Mon, 2009-04-13 at 12:09 -0300, Leonardo Ferreira Fontenelle wrote: The freedesktop module is used for software we don't translate ourselves (at least not with GNOME infrastructure). How should translators submit translations? Bug reports? I took some days before replying because I didn't really know anything about how these are handled, so I wanted to see what people had to say. I think currently the best way to handle this is to open bug reports in bugs.webkit.org to the WebKitGtk component. Almost every commit needs to be reviewed by some of the official reviewers and we haven't really discussed if translations will be handled differently. Feel free to add me (g...@gnome.org) to the CC of any bugs you open there, so I can try and get translations committed =). I understand you are volunteering to review pt_BR translations of WebKitGTK+, but I don't believe the WebKitGTK+ team will be able to review e. g. Arabic, French and Nepalese translations. If the WebKitGTK+ team is concerned with PO files being well-formed, it might be better to have some automatic way to test it; you might consider using Translation Project, Transifex, Pootle or something like that. Another option would be having a clone of webkitgtk at git.gnome.org; the GNOME translators would translate, and the WebKitGTK+ developers would incorporate regularly the GNOME translations to the official repository. AFAIK that's what the system-tools-backend team does. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
GTK+ branched
I've just created a stable gtk-2-16 branch. Future 2.16.x releases will be made off that branch, while development towards 2.18 proceeds on master. Matthias ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Checking out certain subdir of module
Hello, I want to know if there is certain easy way of only checking out po dir certain module with git. While we are using CVS and SVN, we as committers can only checkout po dir of certain module, which will reduce network traffic a lot for large modules such as gtk+. Thanks. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
