[zanata-devel] Gettext header fields

[Sean Flanigan]

On 08/04/11 16:59, James Ni wrote:
> 
> 
> ----- Original Message -----
>> Dean, James,
>>
>> See especially #5 below!
>>
>> The GNU gettext manual has a few things to say about the key-value
>> fields in the header.
>> http://www.gnu.org/s/hello/manual/gettext/Header-Entry.html
>>
>> In particular, these fields should come from xgettext (or more
>> generally, the source document, ie POT):
>> Project-Id-Version
>> Report-Msgid-Bugs-To
>> POT-Creation-Date
>>
>> and these fields are mentioned as specific to the PO file:
>> PO-Revision-Date
>> Last-Translator
>> Language-Team
>> Language
>> Content-Type
>> Content-Transfer-Encoding
>> Plural-Forms
>>
>>
>> In the Java PO client, the POT fields mentioned above are imported
>> into
>> Resource/HDocument, (along with
>> MIME-Version
>> Content-Type
>> Content-Transfer-Encoding),
>> and written out as-is when generating a POT file.
>>
>>
>> When importing a PO file, we preserve
>> PO-Revision-Date
>> Last-Translator
>> Language-Team
>> Language
>> Plural-Forms
>> X-Generator
>> <any other fields>
>>
>> but not the POT fields
>> Project-Id-Version
>> Report-Msgid-Bugs-To
>> POT-Creation-Date
>> MIME-Version
>> Content-Type
>> Content-Transfer-Encoding
>>
>>
>> I think this importing is mostly correct, but:
>>
>> 1. Ideally, we should use each file's (POT or PO) declared
>> MIME-Version
>> Content-Type
>> Content-Transfer-Encoding
>> when reading, to ensure we use the correct character encoding.
>> 2. Once we've read the file, it's probably not necessary to store
>> which
>> MIME-Version/Content-Type/Content-Transfer-Encoding was used.
>> (We currently do store it, but only for POT.)
> 
> Actually, I think we also store this three entries for PO. look at http://code.google.com/p/flies/wiki/RestExtensions#For_TranslationsResource
> In "entries" of "extension", we store this three entries using {"key":"","value":""}

Okay.  I haven't looked at what Python does here, I was just describing
the Java implementation.  At present the server will just store any
key-value pairs you give it, so if you include these values, they will
be persisted.

However, these three fields are really only artefacts of the storage
mechanism (the encoding in the gettext file), so I don't think we should
store them in the server.

>> 3. We should generate reasonable values for
>> MIME-Version/Content-Type/Content-Transfer-Encoding when exporting PO
>> or
>> POT files.
>> 4. Important: we should *copy*
>> Project-Id-Version
>> Report-Msgid-Bugs-To
>> POT-Creation-Date
>> from the template (Resource/HDocument) when generating PO files.
> 
> This also make me confuse, since we could also read
"Project-Id-Version" and "POT-Creation-Date" from "entries" of
"extensions" of TranslationsResource, without the template. Normally,
the po files also have these entries, when importing po, the server also
preserve these entries using "entries" of "extension".

But the server shouldn't have to.  The server should be storing POT
fields against the *source* document, and shouldn't need to store
redundant copies against the target documents too.

"Project-Id-Version" and "POT-Creation-Date" might be out-of date in the
PO file (or in the TranslationsResource).  In a gettext environment,
msgmerge would take care of updating the PO file with these POT values.
 But we can't expect the user to run msgmerge after exporting PO files;
we need to make sure we use the correct values.

But as I said, this filtering/copying should be done on the server.  As
with comments, the clients should just pass these values straight
through in both directions.

>> 5. Most important: we need to test that the PO fields
>> PO-Revision-Date
>> Last-Translator
>> Language-Team
>> Language
>> Plural-Forms
>> X-Generator
>> <minus the POT fields>
>> <plus any other fields>
>> are preserved during a PO file's round trip through Zanata.
>>
>> #1, #2 and #3 are client-side issues, but probably not high priority
>> since everything is probably UTF-8. #4 is something we should handle
>> on
>> the server in ResourceUtils.transferToTranslationsResourceExtensions()
>> if only to avoid implementing it once per client.
>>
>> #5 is basically what we need to do with PO metadata right now, in
>> sprint
>> 22.


-- 
Sean Flanigan

Senior Software Engineer
Engineering - Internationalisation
Red Hat

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 553 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/zanata-devel/attachments/20110408/558eccae/attachment.sig>