Re: Translate Gnome 3.4 for Ubuntu 12.04
Hello Andre, Sorry the Reply All should be clicked not Reply. What I would like you check is that the state of Khmer is Inactive and the progress bar is still 0% translation even I finished 100%. Please see the link below for the problem with Khmer. http://l10n.gnome.org/vertimus/accerciser/master/po/km/level1/ Regards, Sokhem On 06-Feb-12 4:39 PM, Andre Klapper wrote: Hi Khoem, please answer to the mailing list instead of sending me private emails, so others can also help if I'm not around or busy. On Mon, 2012-02-06 at 10:39 +0700, Khoem Sokhem wrote: Hello Andre, You are marked as the team coordinator on http://l10n.gnome.org/teams/km/ so yes, you can go ahead. :) In case that you do not have git commit access, please ping on this mailing list after some translations have been uploaded to l10n.gnome.org by posting links to the files. Also note https://live.gnome.org/TranslationProject/LocalisationGuide#Choosing_the_first_packages_to_translate andre I have uploaded 3 files to l10n.gnome.org in the first step. and I noticed that the files are pending... Could you please check on this? The files are: http://l10n.gnome.org/vertimus/accerciser/master/po/km/level1/ http://l10n.gnome.org/vertimus/aisleriot/master/po/km/level1/ http://l10n.gnome.org/vertimus/alacarte/master/po/km/level1/ Please do not archive your actions, as this hides them from http://l10n.gnome.org/vertimus/accerciser/master/po/km . Not sure what you would like me to "check on this". andre ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
[gnome-terminal] (10 commits) Created branch gnome-3-4
The branch 'gnome-3-4' was created. Summary of new commits: 5f95021... Use new gtk workarea API ea2bf3a... Add 'encoding' profile setting 169654b... Make eggsmclient work on non-X backends fc877ab... Add runtime checks for X11 specific code e1d5fbd... Version 3.3.0 2463393... Updated Spanish translation cc15acf... Updated Slovenian translation ee69474... Updated Norwegian bokmål translation bfe1a67... Updated Traditional Chinese translation(Hong Kong and Taiwa 1f4b0aa... Updated Galician translations ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Bugzilla for freeze break requests?
On Tue, 2012-02-07 at 13:15 +0100, Andre Klapper wrote: > On Thu, 2011-09-22 at 22:44 +0100, Bastien Nocera wrote: > > 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. > > > After having talked to Olav Vitters at FOSDEM I (or we?) would like to > propose using Bugzilla flags for freeze break requests in GNOME 3.5. Awesome! > Personally I consider keywords too cumbersome plus too easy to forget. > > Please also read Olav's initial comments on this thread again: > https://mail.gnome.org/archives/desktop-devel-list/2011-September/msg00147.html > > This proposal applies to those Bugzilla products which already have a > "GNOME Target" field (based on their Bugzilla classification / GNOME > moduleset). > > > https://live.gnome.org/ThreePointThree#Schedule lists: > > | Development Stage | To decide | To notify > ++---+-- > | UI Freeze | 2x rel-team | gnome-doc > | API/ABI Freeze | 2x rel-team | --- > | String Change Announce | --- | gnome-i18n, gnome-doc The "String change announce" period should be a simple CC: rather than a new flag. > | String Freeze | 2x gnome-i18n | rel-team, gnome-doc > | Hard Code Freeze | 2x rel-team | --- > > Initially I favored having three flags (r-t, doc, i18n) but that leaves > us with the problem how to implement the notifications. > Hence I propose five flags. Is it possible to add CC: for patch flags? Because it's really the patches that should have the flags, not the bug itself. > IIRC flags can either refer to reports or attachments. For code changes > a patch to review is needed, however trivial changes could easily be > committed without having the hassle to attach a patch first. Undecided. > > In case a comment can automatically be added to the bug report when a > request flag is set (Olav should know), the comment could include > reasons for receiving that bugmail (team X to decide; team Y only > notified) and expectations (2 members of team X to add "Yes/No" comments > to the bug report, 2nd member with "Yes" comment must set requested flag > to "approved"). Overall, I don't really care about how it's implemented in Bugzilla itself, as long as the UI isn't overly cumbersome, and we can hide those UI elements when outside the freezes. Glad to see movement on it! 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: > 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. After having talked to Olav Vitters at FOSDEM I (or we?) would like to propose using Bugzilla flags for freeze break requests in GNOME 3.5. Personally I consider keywords too cumbersome plus too easy to forget. Please also read Olav's initial comments on this thread again: https://mail.gnome.org/archives/desktop-devel-list/2011-September/msg00147.html This proposal applies to those Bugzilla products which already have a "GNOME Target" field (based on their Bugzilla classification / GNOME moduleset). Flags are displayed in Bugzilla as a dropdown menu. The following statuses can be possible: * (flag never requested) * ? (requested) * - (rejected) * + (approved) Flags can be queried for, however it's better if an email is automatically sent to affected parties whenever a request flag has been set (Olav said he'd investigate once some more Bugzilla maintenance work has been done, hence targetting GNOME 3.5 instead of 3.3). Doing this via pseudo accounts (like "string-freeze-br...@gnome.bugs") would allow non-affected but interested parties (like distributions) to also receive notifications via their Bugzilla users watchlist. https://live.gnome.org/ThreePointThree#Schedule lists: | Development Stage | To decide | To notify ++---+-- | UI Freeze | 2x rel-team | gnome-doc | API/ABI Freeze | 2x rel-team | --- | String Change Announce | --- | gnome-i18n, gnome-doc | String Freeze | 2x gnome-i18n | rel-team, gnome-doc | Hard Code Freeze | 2x rel-team | --- Initially I favored having three flags (r-t, doc, i18n) but that leaves us with the problem how to implement the notifications. Hence I propose five flags. IIRC flags can either refer to reports or attachments. For code changes a patch to review is needed, however trivial changes could easily be committed without having the hassle to attach a patch first. Undecided. In case a comment can automatically be added to the bug report when a request flag is set (Olav should know), the comment could include reasons for receiving that bugmail (team X to decide; team Y only notified) and expectations (2 members of team X to add "Yes/No" comments to the bug report, 2nd member with "Yes" comment must set requested flag to "approved"). andre -- mailto:ak...@gmx.net | failed http://blogs.gnome.org/aklapper ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
