[pacman-dev] Pacman 3.3.1 release?
Any blockers or objections to going with what we pretty much have right now? We'll need a (short) translation period of course as we updated and added some messages, but I can't think of much else. -Dan
2009/9/16, Dan McGee <dpmcgee@gmail.com>:
Any blockers or objections to going with what we pretty much have right now? We'll need a (short) translation period of course as we updated and added some messages, but I can't think of much else.
Go for it! -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it
Dan McGee wrote:
Any blockers or objections to going with what we pretty much have right now? We'll need a (short) translation period of course as we updated and added some messages, but I can't think of much else.
All makepkg issues I know about have been address so I am happy for a release to be made. Allan
On Wed, Sep 16, 2009 at 1:57 PM, Dan McGee <dpmcgee@gmail.com> wrote:
Any blockers or objections to going with what we pretty much have right now? We'll need a (short) translation period of course as we updated and added some messages, but I can't think of much else.
One objection : someone (probably me) should actually update one translation to check everything is fine before any translation period, even minor ones. Many times I detected some problems while translating after the string freeze, and it was obviously too late to fix. So if this could be done systematically, it would be perfect :)
2009. 09. 16, szerda keltezéssel 14.11-kor Xavier ezt írta:
On Wed, Sep 16, 2009 at 1:57 PM, Dan McGee <dpmcgee@gmail.com> wrote:
Any blockers or objections to going with what we pretty much have right now? We'll need a (short) translation period of course as we updated and added some messages, but I can't think of much else.
One objection : someone (probably me) should actually update one translation to check everything is fine before any translation period, even minor ones. Many times I detected some problems while translating after the string freeze, and it was obviously too late to fix. So if this could be done systematically, it would be perfect :)
+1 for Xavier's suggestion, see also: http://mailman.archlinux.org/pipermail/pacman-dev/2009-July/009064.html Someone should collect the problematic strings and fix them in a commit. Personally I can recall two of them: 1. " -u, --sysupgrade upgrade all outdated packages (-uu enables downgrade)\n" I have no better suggestion. 2. "no database for package: %s\n" (in pacman/sync.c) The second one should be something like "no Server URL for package: %s\n" Bye PS: +1 for 3.3.1 release, I can't see any serious unfixed issue in bug tracker since 3.3.
On Wed, Sep 16, 2009 at 2:29 PM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
+1 for Xavier's suggestion, see also: http://mailman.archlinux.org/pipermail/pacman-dev/2009-July/009064.html
Someone should collect the problematic strings and fix them in a commit. Personally I can recall two of them: 1. " -u, --sysupgrade upgrade all outdated packages (-uu enables downgrade)\n" I have no better suggestion. 2. "no database for package: %s\n" (in pacman/sync.c) The second one should be something like "no Server URL for package: %s\n"
What I proposed is much less ambitious : I just want to do a simple pass on the new/modified strings before requesting for translations (instead of doing it after), for eliminating the obvious mistakes Anyone is welcome do send patches to improve message consistency / coherence / clarity / whatever. Even if you are not sure of the english, if you know a message does not accurately capture what the code is doing/reporting, just write a patch anyway. I am sure it will be a pleasure for Dan to check/improve the english :)
On Wed, Sep 16, 2009 at 16:12, Xavier <shiningxc@gmail.com> wrote:
On Wed, Sep 16, 2009 at 2:29 PM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
+1 for Xavier's suggestion, see also: http://mailman.archlinux.org/pipermail/pacman-dev/2009-July/009064.html
Someone should collect the problematic strings and fix them in a commit. Personally I can recall two of them: 1. " -u, --sysupgrade upgrade all outdated packages (-uu enables downgrade)\n" I have no better suggestion. 2. "no database for package: %s\n" (in pacman/sync.c) The second one should be something like "no Server URL for package: %s\n"
What I proposed is much less ambitious : I just want to do a simple pass on the new/modified strings before requesting for translations (instead of doing it after), for eliminating the obvious mistakes
This would be very good to have! -- Roman Kyrylych (Роман Кирилич)
On Wed, Sep 16, 2009 at 7:11 AM, Xavier <shiningxc@gmail.com> wrote:
On Wed, Sep 16, 2009 at 1:57 PM, Dan McGee <dpmcgee@gmail.com> wrote:
Any blockers or objections to going with what we pretty much have right now? We'll need a (short) translation period of course as we updated and added some messages, but I can't think of much else.
One objection : someone (probably me) should actually update one translation to check everything is fine before any translation period, even minor ones. Many times I detected some problems while translating after the string freeze, and it was obviously too late to fix. So if this could be done systematically, it would be perfect :)
In the right directories, of course: make pacman.pot-update make libalpm.pot-update Then I think you can just run make and it will regen the po files as well? -Dan
On Wed, Sep 16, 2009 at 7:11 AM, Xavier <shiningxc@gmail.com> wrote:
On Wed, Sep 16, 2009 at 1:57 PM, Dan McGee <dpmcgee@gmail.com> wrote:
Any blockers or objections to going with what we pretty much have right now? We'll need a (short) translation period of course as we updated and added some messages, but I can't think of much else.
One objection : someone (probably me) should actually update one translation to check everything is fine before any translation period, even minor ones. Many times I detected some problems while translating after the string freeze, and it was obviously too late to fix. So if this could be done systematically, it would be perfect :)
Xavier and I hammered out the string changes tonight (thanks!) and we pushed a handful of patches out to *maint*. Be sure anyone about to update their translation is doing it off the correct branch, or use the files here: http://code.toofishes.net/pacman/po_files/ Does someone more motivated than I want to make sure translators know we are ready for their submissions, and then handle the incoming submissions and get them prepped for merging? This just involves the usual start a git branch, import the submission, sanitize and check the incoming translation (copy po file in place, run "make <lang>.po-update", run make and make sure all messages are translated, rinse, repeat). fr and en_GB are already done. -Dan
2009/9/16, Dan McGee <dpmcgee@gmail.com>:
Does someone more motivated than I want to make sure translators know we are ready for their submissions
Done! I just sent an email to the translators. -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it
On Thu, Sep 17, 2009 at 6:32 AM, Dan McGee <dpmcgee@gmail.com> wrote:
Does someone more motivated than I want to make sure translators know we are ready for their submissions, and then handle the incoming submissions and get them prepped for merging? This just involves the usual start a git branch, import the submission, sanitize and check the incoming translation (copy po file in place, run "make <lang>.po-update", run make and make sure all messages are translated, rinse, repeat).
Giovanni, do you want to take this job back ? :) You already did in the past, but I could refresh your memory, detailing a bit more the steps described by Dan above. I could also share two or three simple helper scripts that I used last time , which simplifies the task of updating and checking each translation.
2009/9/17, Xavier <shiningxc@gmail.com>:
Giovanni, do you want to take this job back ? :) You already did in the past, but I could refresh your memory, detailing a bit more the steps described by Dan above. I could also share two or three simple helper scripts that I used last time , which simplifies the task of updating and checking each translation.
I could try doing that, if you refresh my memory and give me some simple helper script. Let's try... -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it
On Thu, Sep 17, 2009 at 2:24 PM, Giovanni Scafora <giovanni@archlinux.org> wrote:
2009/9/17, Xavier <shiningxc@gmail.com>:
Giovanni, do you want to take this job back ? :) You already did in the past, but I could refresh your memory, detailing a bit more the steps described by Dan above. I could also share two or three simple helper scripts that I used last time , which simplifies the task of updating and checking each translation.
I could try doing that, if you refresh my memory and give me some simple helper script. Let's try...
- clone / update latest git repo - create a maint branch : git checkout -b maint origin/maint - translation branch : git checkout -b translation maint now for each translation , for example "de" 1) put the two de.po files in place 2) ./update-po de 3) ./check-po de if there are some errors / untranslated or fuzzy messages left, report them back to the maintainer and reset git (git reset --hard) 4) git commit -a -s --author "Foo Bar <foo@bar> -m "Update de translation" from time to time you can run ./stat-po
2009/9/17, Xavier <shiningxc@gmail.com>:
- clone / update latest git repo - create a maint branch : git checkout -b maint origin/maint - translation branch : git checkout -b translation maint
now for each translation , for example "de" 1) put the two de.po files in place 2) ./update-po de 3) ./check-po de if there are some errors / untranslated or fuzzy messages left, report them back to the maintainer and reset git (git reset --hard) 4) git commit -a -s --author "Foo Bar <foo@bar> -m "Update de translation"
from time to time you can run ./stat-po
OK, I will be trying with Hungarian, Turkish and Kazakh translations. Thanks! -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it
On Wed, Sep 16, 2009 at 1:57 PM, Dan McGee <dpmcgee@gmail.com> wrote:
Any blockers or objections to going with what we pretty much have right now? We'll need a (short) translation period of course as we updated and added some messages, but I can't think of much else.
a last minute bug maybe : http://bugs.archlinux.org/task/16210
participants (6)
-
Allan McRae
-
Dan McGee
-
Giovanni Scafora
-
Nagy Gabor
-
Roman Kyrylych
-
Xavier