Re: last date?
Hi! Am Donnerstag, den 22.09.2011, 09:48 +0530 schrieb திவாஜி : > where does one get to see the "last date for translations" > announcement? Please note that people might do releases before the actual "tarballs due"-date due to work/holidays/whatever so don't try to finish things on the last minute. However, even if you fail to be in the .0 release your translation will appear in the .1 which is used by all major distros. Regards, Johannes ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String additions to 'gnome-shell.master'
Op Wo, 2011-09-21 om 21:12 +0200 skryf Frederic Peters: > GNOME Status Pages wrote: > > > This is an automatic notification from status generation scripts on: > > http://l10n.gnome.org. > > > > There have been following string additions to module 'gnome-shell.master': > > > > + "Removable Devices" > > > > Note that this doesn't directly indicate a string freeze break, but it > > might be worth investigating. > > That string was not marked for translation; I just fixed that. Thanks for catching that, Fred. I want to remind you of this page describing a way to catch these things earlier: https://live.gnome.org/TranslationProject/DevGuidelines/Test%20internationalization Keep well Friedel -- Recently on my blog: http://translate.org.za/blogs/friedel/en/content/virtaal-070-released ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: last date?
2011/9/22 Johannes Schmid > Hi! > > Please note that people might do releases before the actual "tarballs > due"-date due to work/holidays/whatever so don't try to finish things on > the last minute. > My effort was at 100% and came down to 99% with the last minute additions. I just want to know when to go and wipe those last minute changes in the strings. :-))) regards drtv -- http://www.swaminathar.org/ http://aanmikamforyouth.blogspot.com/ http://techforelders.blogspot.com/ ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Assamese translation commit request
Hi, I filed a bug for Assamese translation commit. Can someone please help commit these files? Link: https://bugzilla.gnome.org/show_bug.cgi?id=659595 Thanks in advance, Regards, Nilamdyuti Goswami ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: 3.2 Release Notes Available for Translation
FYI, I have updated the screenshots for one last time to not display blurred information. This should not really affect translated screenshots though, as there are no "real" UI changes. andre -- mailto:ak...@gmx.net | failed http://blogs.gnome.org/aklapper | http://www.openismus.com ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
[gnome-bluetooth] Created branch gnome-3-2
The branch 'gnome-3-2' was created pointing to: 891adaf... Updated Assamese Translations:bugzilla#659595 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
pybliographer 1.2.15 will be released soon
Hi, I plan to push a new release of pybliographer next week. Please, check your translations! Thanks! Zoltan ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Using Bugzilla for freeze break requests?
Heya, After having to send in another code freeze break request e-mail, I realised that the process is problematic. Apart from the release team and the patch sender, nobody else knows about the freeze break request, or about the status of the request. I think that, at the very least for GNOME 3.4 onwards, we should switch to using a keyword in bugzilla, and the release-team, docs team and i18n teams can monitor newly request breaks, through RSS feeds (the design team does that), and get the keywords cleared when the freeze break has a result. That means that there's no problems with the timeline (patches that go in before the request got accepted for example), accountability and traceability, as well as visibility for the bugsquad and QA teams in downstream communities. Opinions? Cheers ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Bugzilla for freeze break requests?
On Thu, 2011-09-22 at 22:44 +0100, Bastien Nocera wrote: > Heya, > > After having to send in another code freeze break request e-mail, I > realised that the process is problematic. Apart from the release team > and the patch sender, nobody else knows about the freeze break request, > or about the status of the request. > > I think that, at the very least for GNOME 3.4 onwards, we should switch > to using a keyword in bugzilla, and the release-team, docs team and i18n > teams can monitor newly request breaks, through RSS feeds (the design > team does that), and get the keywords cleared when the freeze break has > a result. > > That means that there's no problems with the timeline (patches that go > in before the request got accepted for example), accountability and > traceability, as well as visibility for the bugsquad and QA teams in > downstream communities. > > Opinions? For example, nobody apart from the release-team here would know that I would have requested a freeze break for https://bugzilla.gnome.org/show_bug.cgi?id=659826 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Bugzilla for freeze break requests?
On Thu, Sep 22, 2011 at 5:44 PM, Bastien Nocera wrote: > Heya, > > After having to send in another code freeze break request e-mail, I > realised that the process is problematic. Apart from the release team > and the patch sender, nobody else knows about the freeze break request, > or about the status of the request. > > I think that, at the very least for GNOME 3.4 onwards, we should switch > to using a keyword in bugzilla, and the release-team, docs team and i18n > teams can monitor newly request breaks, through RSS feeds (the design > team does that), and get the keywords cleared when the freeze break has > a result. > > That means that there's no problems with the timeline (patches that go > in before the request got accepted for example), accountability and > traceability, as well as visibility for the bugsquad and QA teams in > downstream communities. > > Opinions? > I'm in favour of anything that makes the process more transparent and less annoying. Of course, one of the main purposes of freezes is to slow down the commit rate, so some annoyance will have to remain as a deterrent... ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Bugzilla for freeze break requests?
On Thu, 2011-09-22 at 18:28 -0400, Matthias Clasen wrote: > On Thu, Sep 22, 2011 at 5:44 PM, Bastien Nocera wrote: > > Heya, > > > > After having to send in another code freeze break request e-mail, I > > realised that the process is problematic. Apart from the release team > > and the patch sender, nobody else knows about the freeze break request, > > or about the status of the request. > > > > I think that, at the very least for GNOME 3.4 onwards, we should switch > > to using a keyword in bugzilla, and the release-team, docs team and i18n > > teams can monitor newly request breaks, through RSS feeds (the design > > team does that), and get the keywords cleared when the freeze break has > > a result. > > > > That means that there's no problems with the timeline (patches that go > > in before the request got accepted for example), accountability and > > traceability, as well as visibility for the bugsquad and QA teams in > > downstream communities. > > > > Opinions? > > > > I'm in favour of anything that makes the process more transparent and > less annoying. > Of course, one of the main purposes of freezes is to slow down the > commit rate, so some annoyance will have to remain as a deterrent... I'm guessing that we'd need to refine the criteria for requesting freeze breaks, and that the release team would remove the keyword and put a reason why it didn't match the criteria in those cases. Cheers ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Bugzilla for freeze break requests?
On Thu, 2011-09-22 at 22:44 +0100, Bastien Nocera wrote: > Heya, > > After having to send in another code freeze break request e-mail, I > realised that the process is problematic. Apart from the release team > and the patch sender, nobody else knows about the freeze break request, > or about the status of the request. Who else needs to know about it? For UI and string freeze breaks, you have to notify the docs resp. i18n teams. The people who are interested in these sorts of things are subscribed to the mailing lists where they can find out about them. > I think that, at the very least for GNOME 3.4 onwards, we should switch > to using a keyword in bugzilla, and the release-team, docs team and i18n > teams can monitor newly request breaks, through RSS feeds (the design > team does that), and get the keywords cleared when the freeze break has > a result. If I don't get email notifications, I can pretty much guarantee I won't deal with it promptly. I don't think you can subscribe to keywords in Bugzilla to get emails when bugs are tagged. I understand we'd get better tracking, but using Bugzilla is a lot more work than sending an email. I gave a docs ack for one UI freeze break request while on vacation from my phone. Using Bugzilla on a phone is unpleasant. Bugzilla is great for making sure stuff doesn't get lost. Do we have a real problem of requests getting lost? -- Shaun ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
clutter "default:LTR"
Many translations in clutter for "default:LTR" are broken; this causes a warning at startup. http://git.gnome.org/browse/clutter/tree/clutter/clutter-main.c#n485 Here's what seems to be affected: po/da.po:msgid "default:LTR" po/da.po-msgstr "" po/kn.po:msgid "default:LTR" po/kn.po-msgstr "" po/or.po:msgid "default:LTR" po/or.po-msgstr "ପୂର୍ବ ନିର୍ଦ୍ଧାରିତ:LTR" po/pa.po:msgid "default:LTR" po/pa.po-msgstr "" po/pt_BR.po:msgid "default:LTR" po/pt_BR.po-msgstr "Padro: LTR" po/ta.po:msgid "default:LTR" po/ta.po-msgstr "முன்னிருப்பு :LTR" po/te.po:msgid "default:LTR" po/te.po-msgstr "" po/uk.po:msgid "default:LTR" po/uk.po-msgstr "типово:LTR" po/zh_HK.po:msgid "default:LTR" po/zh_HK.po-msgstr "預設：LTR" po/zh_TW.po:msgid "default:LTR" po/zh_TW.po-msgstr "預設：LTR" ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: clutter "default:LTR"
hi Colin; thanks for catching this. On 23 September 2011 02:29, Colin Walters wrote: > Many translations in clutter for "default:LTR" are broken; this causes a > warning at startup. > > http://git.gnome.org/browse/clutter/tree/clutter/clutter-main.c#n485 > > Here's what seems to be affected: > > po/da.po:msgid "default:LTR" > po/da.po-msgstr "" > po/kn.po:msgid "default:LTR" > po/kn.po-msgstr "" > po/or.po:msgid "default:LTR" > po/or.po-msgstr "ପୂର୍ବ ନିର୍ଦ୍ଧାରିତ:LTR" > po/pa.po:msgid "default:LTR" > po/pa.po-msgstr "" > po/pt_BR.po:msgid "default:LTR" > po/pt_BR.po-msgstr "Padro: LTR" > po/ta.po:msgid "default:LTR" > po/ta.po-msgstr "முன்னிருப்பு :LTR" > po/te.po:msgid "default:LTR" > po/te.po-msgstr "" > po/uk.po:msgid "default:LTR" > po/uk.po-msgstr "типово:LTR" > po/zh_HK.po:msgid "default:LTR" > po/zh_HK.po-msgstr "預設：LTR" > po/zh_TW.po:msgid "default:LTR" > po/zh_TW.po-msgstr "預設：LTR" to the translators: this works exactly like the identical string in gtk+: http://git.gnome.org/browse/gtk+/tree/gtk/gtkmain.c#n843 ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: clutter "default:LTR"
Le jeudi 22 septembre 2011 à 21:29 -0400, Colin Walters a écrit : > Many translations in clutter for "default:LTR" are broken; this causes a > warning at startup. > > http://git.gnome.org/browse/clutter/tree/clutter/clutter-main.c#n485 > > Here's what seems to be affected: > > po/da.po:msgid "default:LTR" > po/da.po-msgstr "" > po/kn.po:msgid "default:LTR" > po/kn.po-msgstr "" > po/or.po:msgid "default:LTR" > po/or.po-msgstr "ପୂର୍ବ ନିର୍ଦ୍ଧାରିତ:LTR" > po/pa.po:msgid "default:LTR" > po/pa.po-msgstr "" > po/pt_BR.po:msgid "default:LTR" > po/pt_BR.po-msgstr "Padro: LTR" > po/ta.po:msgid "default:LTR" > po/ta.po-msgstr "முன்னிருப்பு :LTR" > po/te.po:msgid "default:LTR" > po/te.po-msgstr "" > po/uk.po:msgid "default:LTR" > po/uk.po-msgstr "типово:LTR" > po/zh_HK.po:msgid "default:LTR" > po/zh_HK.po-msgstr "預設：LTR" > po/zh_TW.po:msgid "default:LTR" > po/zh_TW.po-msgstr "預設：LTR" I understand that 'default' being translated is a bug. However, what about an empty string (da/kn/pa/te)? The standard behaviour of gettext is to return the msgid when msgstr is empty, isn't it? Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
