[Project-ideas] Creating a translation library for Mozilla DTD and similar documents

[Tirtha Chatterjee]

On Sat, Mar 24, 2012 at 7:45 PM, Tirtha Chatterjee
<tirtha.p.chatterjee at gmail.com> wrote:
> On Sat, Mar 24, 2012 at 12:59 AM, Tirtha Chatterjee
> <tirtha.p.chatterjee at gmail.com> wrote:
>> I want to work on bringing translation support for files like Mozilla
>> DTD through a desktop application.
>> I have studied the format of Mozilla DTDs and property files in
>> detail, and found that it has these salient differences with the POT
>> format -
>>
>> 1. The source string and translated string are in different files
>> 2. The text is bound to the GUI components of the chrome, so they have
>> an extra property
>> 3. They explicitly specify a keyboard accelerator
>>
>> This can either be implemented as a C library that can be reused in
>> gtranslator, and then provide a Qt wrapper over it, and use it for
>> Lokalize. This approach, however, has a problem
>
> Okay, I looked at the sources of gtranslator, and realized that it
> will be easier to implement the support as a library, and then
> integrate it in gtranslator. We can later extend this, and have a Qt
> wrapper that works with Lokalize. But for now, since the gtranslator
> code does not have an existing way of translating multiple file
> formats, I think creating a reusable library in glib and C is best.
> I'll try to write a sample mockup program that reads through .DTD
> files and extract info from them, and display them in a tabular format
> after storing them in GLists.
>
> What do you think?

I decided to use flex scanner to extract information from the
properties and dtd files, and storing them in a GHashTable (where the
components will be the keys, and a structure containing the
corresponding strings -- source and target --will be values).

>
>>
>> The Lokalize and GTranslator source codes have to be drastically
>> changed to allow a library to provide its translation catalog. Also,
>> I'm not very strong with GLib.
>>
>> As an alternative, Lokalize already has a class called Catalog which
>> has been subclassed for Pot and XLIFF files. These catalogs simply
>> need to be modified so that it uses two separate files, one for source
>> strings, another for target string (same file for POT or XLIFF,
>> different in case of DTDs). Also, there needs to be a field added that
>> stores the GUI component, which will be turned off in case of file
>> formats which do not use them.
>> This would be an easier, and in my opinion, a much easier way to
>> implement support for these files.
>>
>> Please advise me on which alternative is better, and any points that I
>> may have missed out.
>>
>> --
>> Regards
>> Tirtha Chatterjee
>> KDE developer
>> http://wyuka.co.cc/
>
>
>
> --
> Regards
> Tirtha Chatterjee
> KDE developer
> http://wyuka.co.cc/



-- 
Regards
Tirtha Chatterjee
KDE developer
http://wyuka.co.cc/