[zanata-devel] glossary push works for python client

[Sean Flanigan]

On 08/26/2011 12:11 PM, James Ni wrote:
> ----- Original Message -----
>> (cc-ing zanata-devel at redhat.com)
>>
>>
>>
>> On 08/25/2011 11:53 PM, James Ni wrote:
>>> Hi, Alex, Sean
>>>
>>> I added MediaType.APPLICATION_JSON in @Consumes of PUT method of
>>> glossary service on server side, since i always use
>>> "application/json" as Content-Type on client side. After that, i can
>>> push glossary to server successfully.
>>
>> Great!
>>
>> Have you tried GET /glossary (via wget) to see what it looks like?
> 
> Yeah, i can use wget to get a xml format content from server:
> 
> <ns2:Glossary>
> <Entries>
> <ns2:Entry srcLang="en-US">
>   <Term locale="zh-Hans">
>     <content>中</content>
>   </Term>
>   <Term locale="en-US">
>     <content>CN</content>
>   </Term>
>   <sourcereference/>
> </ns2:Entry>
> ........
> </Entries>
> </ns2:Glossary>
> 
> Do you want to add a command to python client to retrieve the
> glossary
from server? I have not add such command yet.

Only if it helps with your testing, it's not required at this stage.  I
think wget should be enough for your testing.

Note that the XML element names will be changing, to something like this:

<ns2:glossary xmlns:ns2="http://zanata.org/namespace/api/">
    <glossary-entries>
        <glossary-entry src-lang="en-US">
            <source-reference></source-reference>
            <glossary-term xml:lang="en-US">
                <comment>Tag: title</comment>
                <content>RPM</content>
            </glossary-term>
            <glossary-term xml:lang="zh">
                <content></content>
            </glossary-term>
        </glossary-entry>
    </glossary-entries>
</glossary>



>>> The command for pushing glossary is "zanata glossary push
>>> GLOSSARY_POFILE --lang=language". currently, only one glossary file
>>> (under current path) for one language can push to server side. If
>>> you
>>> want to push several glossary files with different languages to
>>> server side, i don't have a good solution for that.
>>
>> "zanata glossary push": good, it makes sense to have a subcommand
>> "glossary".
>>
>> Alex, for consistency, I think we should call the maven goal something
>> similar: eg mvn zanata:glossary-push, rather than
>> zanata:push-glossary.
>>
>> For the Maven client, we thought about auto-detecting the locale of
>> the
>> PO file, but it would be tricky to get right in all cases.
>>
>> James, I assume you can call zanata glossary push a second time from
>> the
>> same directory, if you want to push a different language?
> 
> Yes, i can call 'zanata glossary push' a second time from the same
directory when pushing a different language, currently i push zh-CN and
zh-TW for testing
> 

Okay.

>> CSV is the current plan for pushing multiple languages at once.
>>
>> This is Google's description of their CSV format:
>> http://translate.google.com/support/toolkit/bin/answer.py?answer=147854
>>
>> For Maven, we plan to convert 'pos' and 'description' to comments. I
>> suggest making 'description' the first comment, and 'pos' the second
>> comment, because 'description' is usually more interesting.
>>
> 
> OK, I will look through if i can use python to convert CSV format to JSON.

Okay, note that we should apply locale mappings from zanata.xml when
converting the locale IDs given column headings to server-side locale IDs.

so if the CSV looks like this:

"en","es-ES","pos","description"
"account","cuenta","noun","A user's account"

and zanata.xml has:

<locales>
  <locale map-from="es-ES">es</locale>
</locales>

then "cuenta" should be pushed with the locale ID "es", not "es-ES".

We should do the same thing when pushing .po files: if the user says
--lang=es-ES, we would map it to "es" based on the <locales>

>>> There also some other issues i think maybe you could give me some
>>> advice:
>>> 1)zanata.xml
>>> Currently, i still use zanata.xml to get URL address, i am not sure
>>> if it is proper to use project configuration file for glossary
>>> pushing. Otherwise, user have to use --url option every time pushing
>>> glossary to server.
>>
>> Okay, that's fine. As long as we don't make 'project' and
>> 'project-version' required. We might make zanata.xml optional at some
>> point for glossary push, as long as the user supplies --url.
>>
>>> Also, in the zanata.xml, there is locale mapping
>>> info which is needed for pushing glossary.
>>
>> Good point.
>>
>>> 2)How to specify glossary file name
>>> If user want to push Chinese, German and other language glossary
>>> files to server at same time, then how do we specify the glossary
>>> file name?
>>
>> At this stage, we will only push multiple languages when using CSV.
>>
>>> Do we require that glossary file name must include the
>>> locale name, like zh_CN.po, and de_DE.po? similar to software
>>> project?
>>
>> Yes, I think that would be a reasonable requirement when pushing
>> multiple POs at once, if and when we implement that.
>>
>>> Then we can use --lang=zh_CN,de_DE to pushing glossary for
>>> different language at same time. What do you think?
>>
>> When it comes to this, I'd rather just let the user specify the PO
>> filenames. That way this would work:
>> zanata glossary push *.po
> 
> Ok, so you mean we extract the locale name from po file name and
> don't use --lang option to specify the locale?

Yes, but we won't be implementing this feature at this stage.  (It won't
work for FUEL, because they have filenames like FUEL_pa.po instead of
pa.po.)



-- 
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: 554 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/zanata-devel/attachments/20110826/aa1d56b6/attachment.sig>