I tried today to submit cs.po im-chooser translation thru transifex, however the first time I got error about "some technical problem", second time I tried that it says that the diff is empty and it will not commit. But web repo view shows there is still old file. What's up?
For system-config-httpd the module overview shows some untranslated strings, however I can not get this file. What I see thru web iface is completely translated. How could this happen?
Also one RFE - would i be possible to have also "Get" feature in transifex to download the po in selected language? I am now downloading files thru web front-end but this is not very comfortable and I struggle wherether I have correct files.
The last question which is still not clear to me - how's that with those minus sings and exclamation marks in http://translate.fedoraproject.org/languages/cs/fedora-8 What should I do with them? Or should they be ignored?
Thanx
Adam Pribyl
Adam Pribyl લખ્યું:
I tried today to submit cs.po im-chooser translation thru transifex, however the first time I got error about "some technical problem", second time I tried that it says that the diff is empty and it will not commit. But web repo view shows there is still old file. What's up?
For system-config-httpd the module overview shows some untranslated strings, however I can not get this file. What I see thru web iface is completely translated. How could this happen?
Also one RFE - would i be possible to have also "Get" feature in transifex to download the po in selected language? I am now downloading files thru web front-end but this is not very comfortable and I struggle wherether I have correct files.
The last question which is still not clear to me - how's that with those minus sings and exclamation marks in http://translate.fedoraproject.org/languages/cs/fedora-8 What should I do with them? Or should they be ignored?
Thanx
Adam Pribyl
Hi Adam,
You can file a bug from this link: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20Localization&... OR open a ticket from here: https://hosted.fedoraproject.org/projects/transifex/newticket
Please list the filed bug on this page for future reference & tracking bugs: http://fedoraproject.org/wiki/transifex-bugs
Στις 21-09-2007, ημέρα Παρ, και ώρα 13:07 +0200, ο/η Adam Pribyl έγραψε:
I tried today to submit cs.po im-chooser translation thru transifex, however the first time I got error about "some technical problem", second time I tried that it says that the diff is empty and it will not commit. But web repo view shows there is still old file. What's up?
I think this is fixed now. The problem was tracked by bug #297511.
For system-config-httpd the module overview shows some untranslated strings, however I can not get this file. What I see thru web iface is completely translated. How could this happen?
The statistics page has links in green circles on the left of each language. These files are msgmerged with the POT files and then the stats are calculated and the files produced. You can either download the PO file from the statistics page, or download it from the VCS.
If the stats are different from what you download from the VCS, then the developer hasn't msgmerged and you should download the POT and msgmerge them manually.
Also one RFE - would i be possible to have also "Get" feature in transifex to download the po in selected language? I am now downloading files thru web front-end but this is not very comfortable and I struggle wherether I have correct files.
No, currently transifex does only push. But we can put on the transifex pages more clear links to the stats page.
The last question which is still not clear to me - how's that with those minus sings and exclamation marks in http://translate.fedoraproject.org/languages/cs/fedora-8 What should I do with them? Or should they be ignored?
Those are problems and warnings of the international support of the module, and the developer should know about them. So usually someone needs to open a bug report to the package and let the maintainer know about them to fix them.
Most of them are created because the modules don't use intltool for extraction of the strings.
-d
On Sat, 2007-09-22 at 07:33 +0100, Dimitris Glezos wrote:
Στις 21-09-2007, ημέρα Παρ, και ώρα 13:07 +0200, ο/η Adam Pribyl έγραψε:
The last question which is still not clear to me - how's that with those minus sings and exclamation marks in http://translate.fedoraproject.org/languages/cs/fedora-8 What should I do with them? Or should they be ignored?
Those are problems and warnings of the international support of the module, and the developer should know about them. So usually someone needs to open a bug report to the package and let the maintainer know about them to fix them.
Most of them are created because the modules don't use intltool for extraction of the strings.
FWIW, the fact that transifex's status is dependent on the usage of intltool is, IMHO, a bug. It basically forces people to use the GNOME stack as well as autotools for their project when there's really not a good reason to do so. There are definitely better build systems out there...
Jeremy
Στις 23-09-2007, ημέρα Κυρ, και ώρα 20:18 -0400, ο/η Jeremy Katz έγραψε:
On Sat, 2007-09-22 at 07:33 +0100, Dimitris Glezos wrote:
Στις 21-09-2007, ημέρα Παρ, και ώρα 13:07 +0200, ο/η Adam Pribyl έγραψε:
The last question which is still not clear to me - how's that with those minus sings and exclamation marks in http://translate.fedoraproject.org/languages/cs/fedora-8 What should I do with them? Or should they be ignored?
Those are problems and warnings of the international support of the module, and the developer should know about them. So usually someone needs to open a bug report to the package and let the maintainer know about them to fix them.
Most of them are created because the modules don't use intltool for extraction of the strings.
FWIW, the fact that transifex's status is dependent on the usage of intltool is, IMHO, a bug.
Transifex can handle both of them equally OK; the problem is with Damned Lies (the statistics app, which we are not upstream).
DL supports intltool-based string extraction better than other methods, simply because upstream (GNOME) doesn't have many (any?) modules which don't use intltool.
I've discussed this with the maintainer in the past, and the best solution would be to modularize the part of the code in Damned Lies which does the extraction, in order to be able to choose the method from the XML file, per module, just like we choose the VCS type.
It basically forces people to use the GNOME stack as well as autotools for their project when there's really not a good reason to do so. There are definitely better build systems out there...
+1 to have the choice.
The easiest solution right now would be to go ahead and add the choice in the XML file, so that the viewing template will know and hide the relevant warnings for non-intltool modules.
There would be other issues to solve then (which languages are active? Are all strings there? etc), which I don't know how standardized our i18n is (same variable in all Makefiles?) in order to automate the process and *do* present some warnings (eg. for languages not shipped).
-d
On Mon, 2007-09-24 at 02:13 +0100, Dimitris Glezos wrote:
Στις 23-09-2007, ημέρα Κυρ, και ώρα 20:18 -0400, ο/η Jeremy Katz έγραψε:
On Sat, 2007-09-22 at 07:33 +0100, Dimitris Glezos wrote:
Στις 21-09-2007, ημέρα Παρ, και ώρα 13:07 +0200, ο/η Adam Pribyl έγραψε:
The last question which is still not clear to me - how's that with those minus sings and exclamation marks in http://translate.fedoraproject.org/languages/cs/fedora-8 What should I do with them? Or should they be ignored?
Those are problems and warnings of the international support of the module, and the developer should know about them. So usually someone needs to open a bug report to the package and let the maintainer know about them to fix them.
Most of them are created because the modules don't use intltool for extraction of the strings.
FWIW, the fact that transifex's status is dependent on the usage of intltool is, IMHO, a bug.
Transifex can handle both of them equally OK; the problem is with Damned Lies (the statistics app, which we are not upstream).
Yeah, sorry for the imprecision
DL supports intltool-based string extraction better than other methods, simply because upstream (GNOME) doesn't have many (any?) modules which don't use intltool.
Doubtful that they really have any at this point.
It basically forces people to use the GNOME stack as well as autotools for their project when there's really not a good reason to do so. There are definitely better build systems out there...
+1 to have the choice.
The easiest solution right now would be to go ahead and add the choice in the XML file, so that the viewing template will know and hide the relevant warnings for non-intltool modules.
Well, it should be easy enough to auto-figure out if intltool is being used or not. iirc, intltool depends on POTFILES.in so if it doesn't exist, then no intltool and hide the warnings
There would be other issues to solve then (which languages are active? Are all strings there? etc), which I don't know how standardized our i18n is (same variable in all Makefiles?) in order to automate the process and *do* present some warnings (eg. for languages not shipped).
This is going to vary from build system to build system. And this is a place where we can take advantage of the fact that we're building a binary distribution -- just look in the packages to see what's there.
Trying to support what every build mechanism might support just feels like it's going to get out of hand. Especially when you take into account custom makefiles, etc.
Jeremy