Re: [Qucs-devel] svg/xml format + translations

[Bastien R. <rou...@gm...>]

Le samedi 22 d=E9cembre 2007, Gopala Krishna a =E9crit=A0:
> On Dec 22, 2007 4:42 AM, Stefan Jahn <st...@gr...> wrote:
> > hi there!
>
> hi Stefan,
>
> > just a thought crossing my mind: currently property descriptions
> > of components and anything else concerning it (e.g. name, etc.)
> > can be translated into different langauges easily using linguist.
> >
> > will it be also possible with svg/xml?  have you already considered
> > that?
> >
> > cheers, stefan.
>
> Actually we had assumed translating tags enclosed in "lang" tags in
> pure xml files shouldn't be a problem. But you are right in this
> regard as this becomes tedious.
>
> The possible solutions to this problem are
>
> 1) Write our own small tool - similar to linguist, to help the
> translator to add translations maintaining current format i.e the tool
> adds lang tags to corresponding xml files which is done manually now.
> One disadvantage of the approach is "duplication" of work!
>
> 2) Another solution would be to use linguist itself for translation.
> For this we need a script or program to manually append the
> translatable strings to the corresponding .ts file(as it is pure xml
> file as well ;-)   - similar to lupdate.
> May be we can have one set of ts files dedicated only for xml files.
> In this case, we need to remove the "lang" entries for other languages
> and use the QTranslator, QCoreApplication::translate for the generated
> qm files and friends to translate the text in runtime.
>
> The disadvantage of second approach will be, the xml files will be
> tied only to qucs as far as translation is concerned and hence wont be
> standardizable ;-) .
>
> 3) The final approach is one step ahead of second approach.
> For this we should be able to generate a set of *intermediate* files
> matching the format of linguist (ts files) - similar to tool described
> in second solution. Then the translator can translate these
> *intermediate* files.
> These translations can then be imported to the xml descriptions later
> rather than generating and using qm files.
(I could use a xslt script to convert xml file to xliff file and use lingui=
st=20
but it will be local to a component)

> Reasonable ?
> What are your opinions on these solutions ?
The main problem with both approach is that xliff  (the xml alternativeand =
ts=20
file are language centric. Ie you group all the string to translate then yo=
u=20
translate this language to only one another language.

=46or components, we have a property that we want to translate to a lot of=
=20
different language :-( The "atom" (greek sense) is not the language but the=
=20
component property and personnaly I believe that grouping all the string fo=
r=20
all the component is a bad idea, because User will want to create component=
=20
and centralizing the translation is not a good idea.

Do linguist allow plugin?
BTW does they are a mailling list?

Regards=20

=2D-=20

"ROUCARIES Bastien"
                                              roucaries.bastien+qucs@gmail.=
com
=2D------------------------------------------------------------------------=
=2D-----
DO NOT WRITE TO rou...@gm... OR BE BLACKLISTED