From: Angel V. <an...@ar...> - 2010-04-06 12:39:40
|
Hi, I was trying to build lxtask 0.1.2 to make the package for Arch Linux, then I found a message on fa.po (and other files, I corrected by hand fa.po and tried to build again), the message is like this: fa.po:39: `msgid' and `msgstr' entries do not both end with '\n' Any hints? am I doing something wrong (I don't wanna believe is an error of most of .po files) Cheers -- Angel Velásquez angvp @ irc.freenode.net Arch Linux Trusted User Linux Counter: #359909 http://www.angvp.com |
From: Naveen K. M. <ner...@gm...> - 2010-04-06 12:42:22
|
I had the error as well. Just add '\n' at the end of the strings. 2010/4/6 Angel Velásquez <an...@ar...>: > Hi, > > I was trying to build lxtask 0.1.2 to make the package for Arch Linux, > then I found a message on fa.po (and other files, I corrected by hand > fa.po and tried to build again), the message is like this: > > fa.po:39: `msgid' and `msgstr' entries do not both end with '\n' > > Any hints? am I doing something wrong (I don't wanna believe is an > error of most of .po files) > > Cheers > > > > -- > Angel Velásquez > angvp @ irc.freenode.net > Arch Linux Trusted User > Linux Counter: #359909 > http://www.angvp.com > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > -- Naveen Kumar Molleti Computer Science, IIT Kharagpur |
From: Christoph W. <chr...@go...> - 2010-04-06 13:58:09
|
Am Dienstag, den 06.04.2010, 18:12 +0530 schrieb Naveen Kumar Molleti: > > > > fa.po:39: `msgid' and `msgstr' entries do not both end with '\n' > > > > Any hints? am I doing something wrong (I don't wanna believe is an > > error of most of .po files) For me only fa.po was broken and I fixed it in http://lxde.git.sourceforge.net/git/gitweb.cgi?p=lxde/lxtask;a=commitdiff;h=b3bb2ec3104c269a63ea85db49797fc5bf8c469a Regards, Christop |
From: Martin B. / b. <br...@bs...> - 2010-04-06 14:04:50
|
On Tue, 6 Apr 2010, Angel Velásquez wrote: > I was trying to build lxtask 0.1.2 to make the package for Arch Linux, > then I found a message on fa.po (and other files, I corrected by hand > fa.po and tried to build again), the message is like this: > > fa.po:39: `msgid' and `msgstr' entries do not both end with '\n' > > Any hints? am I doing something wrong (I don't wanna believe is an > error of most of .po files) For fa.po there is a pretty major error where the translator left parts of the string out. I am not sure why and if it could be an accident. In the repo I just added the "missing" parts and that might break things so I have noted the string as fuzzy too - demanding a review. This is how it looks before #: ../src/xfce-taskmanager-linux.c:385 #, c-format msgid "" "Couldn't send signal %d to the task with ID %d\n" "\n" "%s" msgstr "ناتوانی در ارسال علامت %d برای وظیفه با مشخصه %d\n" The missing part is the new line and %s and I just added those. There are no other errors reported so you have to be more specific about fi, fr and frp for me thos see those. See commit 8e63ead504bc21437110e94f0a169c1f937ee82d -- brother |
From: Marty J. <mar...@co...> - 2010-04-06 14:37:32
|
Is there some sort of automated tool we could run to catch this \n mismatch error? It seems to come up quite frequently; and since we are taking translations automatically, it can happen on any checkin. Most often it happens on the "Translator Credit" strings. It would be nice if git builds all the time, not just when we do a release. Let me reemphasize that released tarballs must build. The way I do it is to make dist, and then build and install the tarball in my build area as if I were an ordinary user downloading and installing the new release. Only then do I check in the release bump and upload the tarball to SF. In the last day or so we had a case where a package failed to build because the dependency checking was missing/incorrect in configure. This is another thing that developers must be sensitive to. If you are writing GTK/Glib code, you need to check the "Since" notation in the documentation, satisfy yourself it makes sense from a product perspective to depend on the newer version, and update your version check. We want people to have configure failures rather than build failures. If you add a displayable string, make sure it is marked for translation and before you release anything in tarball form, there needs to be notice to the translation team and a delay to get the translations finished. We have far too many users now to be sloppy about this, and an approval rating anyone would be proud of to defend. I see that Christoph has made further comments while I was writing, which I totally support. On 04/06/2010 10:04 AM, Martin Bagge / brother wrote: > On Tue, 6 Apr 2010, Angel Velásquez wrote: > >> I was trying to build lxtask 0.1.2 to make the package for Arch Linux, >> then I found a message on fa.po (and other files, I corrected by hand >> fa.po and tried to build again), the message is like this: >> >> fa.po:39: `msgid' and `msgstr' entries do not both end with '\n' >> >> Any hints? am I doing something wrong (I don't wanna believe is an >> error of most of .po files) > > For fa.po there is a pretty major error where the translator left parts of > the string out. I am not sure why and if it could be an accident. > In the repo I just added the "missing" parts and that might break things > so I have noted the string as fuzzy too - demanding a review. > > This is how it looks before > #: ../src/xfce-taskmanager-linux.c:385 > #, c-format > msgid "" > "Couldn't send signal %d to the task with ID %d\n" > "\n" > "%s" > msgstr "ناتوانی در ارسال علامت %d برای وظیفه با مشخصه %d\n" > > The missing part is the new line and %s and I just added those. > > There are no other errors reported so you have to be more specific about > fi, fr and frp for me thos see those. > > See commit 8e63ead504bc21437110e94f0a169c1f937ee82d > |
From: Marty J. <mar...@co...> - 2010-04-06 14:41:34
|
I beg your pardon, that was Martin Bagge who made the additional comments. I continue to totally support them ... |
From: Christoph W. <chr...@go...> - 2010-04-06 14:50:24
|
Am Dienstag, den 06.04.2010, 10:41 -0400 schrieb Marty Jack: > I beg your pardon, that was Martin Bagge who made the additional > comments. I continue to totally support them ... I made some comments too ;) and I think we all agree. For me the most important part in your previous mail was: > We have far too many users now to be sloppy about this Seconded! Regards, Christoph |
From: Angel V. <an...@ar...> - 2010-04-06 15:12:24
|
Ok, this is the question there is an automated tool or a magic sed or awk line whick can be applied to fix this?. I can't do the package for lxtask 0.1.2 in Arch Linux, since I won't do "n" diff files and apply "n" patches to fix those \n silly errors. Can we solve this and do a quick and new release? (it's unfair for others package mantainer to make them do patches for fix this). For future versions I agree with other mails where will be a "relese team" or "q&a" who will test it. -- Angel Velásquez angvp @ irc.freenode.net Arch Linux Trusted User Linux Counter: #359909 http://www.angvp.com |
From: Christoph W. <chr...@go...> - 2010-04-06 15:23:05
|
Am Dienstag, den 06.04.2010, 12:12 -0300 schrieb Angel Velásquez: > Can we solve this and do a quick and new release? Yes, IMO we should do a 0.1.2.1 release soon. Reagrds, Christoph |
From: Martin B. / b. <br...@bs...> - 2010-04-06 15:34:55
|
On Tue, 6 Apr 2010, Marty Jack wrote: > Is there some sort of automated tool we could run to catch this \n mismatch error? It seems to come up quite frequently; and since we are taking translations automatically, it can happen on any checkin. Most often it happens on the "Translator Credit" strings. It would be nice if git builds all the time, not just when we do a release. To just get the complete picture of the state of the translations I run intltool-update -m intltool-update -r in the po directory. The -m This will scan for files with translatable content in the source and match those to the files in POTFILES.in, if missing they will be in STDOUT and a file called missing and could be added to POTFILES.in. The -r This will resync all po files present with the pot file. Adding new removing obsolete and marking updated strings as fuzzy ("review" needed). If a file is not well formed (missing a \n in msgstr where there was a \n in msgid for instance) a error will be raised. It checks for other errors too. The -r will however touch ALL files and bump the created timestamp and should not be used if no changes are present, see below for automated things. The tools to use! msgfmt or msgcat can be used to check the files. msgfmt -c file.po This will do the checks and outout the status in STDOUT. If none, continue with next step. If any correct the issue. A common notion is to use msgcat file.po > file.po_copy this will do checks and wrap lines at 80 and so on. The output is in STDOUT so when without errors just catch it and direct it to the original file). For the translators using Pootle ALOT of error and quality checking is hidden under "review" in the interface. It check for missing symbols, new lines, acronyms and such things. The review tool is really easy to use and would ramp things alot if people could use it. I plan to write guides for these in the future but trying them out won't hurt abit. -- brother |
From: PCMan <pcm...@gm...> - 2010-04-07 05:48:13
|
Maybe we should create a set of lxde-devel tools and make this a standard develop-time or build-time dependency of lxde components. It can contains; 1. Project standard autogen.sh 2. A tool helping us generate new project (Makefiles and configure.ac) in a user-friendly, even GUI way. 3. xml-purge tool used to optimize the sizes of glade files. 4. Script used to check and fix errors like missing \n in translations. 5. A tool used to check gtk+ API versions. In gtk+ API doc, they provided lists of new symbols in each releases. We can get those symbols and grep them in our source code to determine minimal gtk+ or glib version. So we can set it properly in configure.ac. 6. A release gate-keeper script running some automated checks such as make dist; tar; configure; make all to make sure the tarball builds, to run checkers for translation, and others. This test tool should be run prior to any tarball release. Then, make all of these tools included in one lxde-devel package.Then developers can get it installed for use in lxde development. It's just a proposal. I myself don't know how to write these scripts since I'm no shell script guru, but I'm sure it's possible. Regarding to release process, I agree with all of you for setting up a release team. For alpha or beta release I think there shouldn't be restrictions since the purpose of alpha or beta release is for helping development. However stable release must be made by release team after QA only. Developers drop mails in the mailing list when new release is suitable and release/QA team make the release after proper testing. Developers should tag the release properly in git and ask the release/QA team to test against git code with that tag. Any comments? On Tue, Apr 6, 2010 at 11:34 PM, Martin Bagge / brother <br...@bs...> wrote: > On Tue, 6 Apr 2010, Marty Jack wrote: > >> Is there some sort of automated tool we could run to catch this \n mismatch error? It seems to come up quite frequently; and since we are taking translations automatically, it can happen on any checkin. Most often it happens on the "Translator Credit" strings. It would be nice if git builds all the time, not just when we do a release. > > To just get the complete picture of the state of the translations I run > intltool-update -m > intltool-update -r > in the po directory. > > The -m > This will scan for files with translatable content in the source and match > those to the files in POTFILES.in, if missing they will be in STDOUT and a > file called missing and could be added to POTFILES.in. > > The -r > This will resync all po files present with the pot file. Adding new > removing obsolete and marking updated strings as fuzzy ("review" needed). > > If a file is not well formed (missing a \n in msgstr where there was a \n > in msgid for instance) a error will be raised. It checks for other errors > too. > The -r will however touch ALL files and bump the created timestamp and > should not be used if no changes are present, see below for automated > things. > > The tools to use! > msgfmt or msgcat can be used to check the files. > msgfmt -c file.po > This will do the checks and outout the status in STDOUT. > If none, continue with next step. If any correct the issue. > > A common notion is to use > msgcat file.po > file.po_copy > this will do checks and wrap lines at 80 and so on. The output is in > STDOUT so when without errors just catch it and direct it to the original > file). > > > For the translators using Pootle ALOT of error and quality checking is > hidden under "review" in the interface. It check for missing symbols, new > lines, acronyms and such things. The review tool is really easy to use and > would ramp things alot if people could use it. I plan to write guides for > these in the future but trying them out won't hurt abit. > > > -- > brother > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > |
From: Christoph W. <chr...@go...> - 2010-04-07 13:54:27
|
Am Mittwoch, den 07.04.2010, 13:48 +0800 schrieb PCMan: > Maybe we should create a set of lxde-devel tools and make this a > standard develop-time or build-time dependency of lxde components. It > can contains; > 1. Project standard autogen.sh I don't think this is a good idea. For GIT snapshots it's ok, but not for releases. Released versions should never require or run automake or autoconf. This makes builds error-prone due to different versions of these tools. Having said this, I find it extremely irritating that some of the apps even run autconf in configure. Regards, Christoph |
From: Martin B. / b. <br...@bs...> - 2010-04-07 20:09:07
|
On Wed, 7 Apr 2010, PCMan wrote: > Maybe we should create a set of lxde-devel tools and make this a > standard develop-time or build-time dependency of lxde components. It > can contains; [...] > Then, make all of these tools included in one lxde-devel package.Then > developers can get it installed for use in lxde development. I do not think you should mix devel tasks and QA tasks. And as I have told you before, when developers touch the po files I find myself tied in merge hell for hours and I can not encourage that at all - please, never touch the po files. AT ALL. Tell me (the list, what ever) that there are strings added/updated and I'll manage the process from there. > Regarding to release process, I agree with all of you for setting up a > release team. For alpha or beta release I think there shouldn't be > restrictions since the purpose of alpha or beta release is for helping > development. However stable release must be made by release team after > QA only. Developers drop mails in the mailing list when new release is > suitable and release/QA team make the release after proper testing. Something like that sounds reasonable enough. -- brother |