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

[Tirtha Chatterjee]

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?

>
> 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/