This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 491435 - Transifex 0.5 doesn't handle outdated POT files correctly
Transifex 0.5 doesn't handle outdated POT files correctly
Status: CLOSED NOTABUG
Product: Fedora Localization
Classification: Fedora
Component: Website (Show other bugs)
unspecified
All Linux
low Severity medium
: ---
: ---
Assigned To: Dimitris Glezos
Diego Búrigo Zacarão
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-20 19:17 EDT by Miloš Komarčević
Modified: 2009-07-03 16:08 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-21 09:57:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Miloš Komarčević 2009-03-20 19:17:34 EDT
Tx 0.5 uses prefers using an outdated repo POT file to generate translation statistics, instead of generating it's own from code and comapring it to the repo one as it used to.

For example: 

1. PO files were for policycoreutils were updated a few weeks ago in CVS, but not the POT file

2. I've grabbed my sr.po from CVS directly and translated it fully

3. Submitted 100% completed sr.po through Tx 0.5, shows up in CVS ok

4. Shows up as 99% completed in sr.po - viewing it I saw that Tx re-merged my submitted sr.po with it's cached, out of date POT
Comment 1 Diego Búrigo Zacarão 2009-03-20 21:30:29 EDT
Alright.

The new Transifex *does* have the ability of creating POT files from the source file when the component is set up as an intltool based project. 

We should ask one of our translators, maybe Piotr, to go through all the components registered for the projects on the new instance, to check if the "i18n type" of each component is setup correctly. I think we have a bunch of components that would need to be set up as intltool ones.

--------

If a component is set up as intltool based, Transifex try to create a new POT file from the source. If it fails, the system uses the current POT, if present, to do the msgmerge.

From where I can see, doing some checking here locally, the policycoreutils intltool support is broken. It points Transifex to use the current POT.

So here is the Q: Should we do not merge intltool based projects when the generation of the POT file fails?

BTW I don't think that leave up to dated PO files with a out to dated POT in a repository is a good practice.
Comment 2 Miloš Komarčević 2009-03-21 05:55:46 EDT
Agreed, and this is a prime example why developers should be automagically hassled if there is a problem with their i18n setup, as suggested in bug #490356, instead of translators filing identical bug reports for multiple modules every release cycle...
Comment 3 Diego Búrigo Zacarão 2009-03-21 09:57:05 EDT
OK,

Ticket Created on the Transifex upstream trac.
http://transifex.org/ticket/152

Lets discuss it there.

Thanks
Comment 4 Miloš Komarčević 2009-03-21 10:42:01 EDT
Just for reference, I have also reported this particular problem with policycoreutils as bug #491476.
Comment 5 Piotr Drąg 2009-07-03 16:08:18 EDT
Mass change of component from Transifex to Website, since all our websites are handled by Transifex now.

Note You need to log in before you can comment on or make changes to this bug.