Hi Alberto,
Alberto Escudero-Pascual wrote:
[This message is a fork from the thread (OOoCon presentation: i18n for
l10n)]
Hi Ivo,
OK, i change the Subject: title to a separate thread. Sorry, i could not
come up with something smarter.
[snip]
Localizing OOo should be as simple as localizing Skype or Google!. If we
I agree, but remember in OOo are a lot of more strings than "What do you
want to search today?" and a "Search" Button. We have a bunch off
different resource types ( res files , officecfg , readme , help ... )
Agree but the main difference in my opinion is not the number of
strings, it is not what stops most of the teams that i am contact with.
I have read this many times in the list, the problem is the amount of
strings... it is NOT... think in the seven different ways that variables
appear in OOo... or the lack of contextual information for translators.
As I remember there are 9 different variables schema's , that's messy.
Did you wrote a issue for that ?
There is the possibillity to add contextual informations ( see Eikes
answer ) , but the developers have to fill in such info.... I remember
that I got a issue to srip out comment blocks from helpcontent2 strings,
because translators do not want to see them ...
Localization of Skype and Google are winners because of their friendly
User Interface for people that want to work with the localization. You
get the software and you are ready to start localizing... we should aim
for that!. It can take 2 years but the goal has to be settled.
It will take a bit more time to come with something perfect but we have
already something on progress in that direction, D&D are going to love
to hear this...Pootle. It is not bullet proof but it does many things
that i dreamed about one year ago. I hate online interfaces ... but the
future translators of OOo they like them...
Can you please give a bit more background information ?
[snip]
Our curent resource system is not yet able to handle WYSIWYG
translation. Solving this would also reduce the download / build times.
This already has been adressed but we have not yet a solution for that.
Nice, who is working on that? is it a development goal?
David did a hack for the res files. Hacking the various xml variants is
bit more complex.
- Include as many languages as possible by default in the source code
limiting the number of patches to submit.
This sounds somehow strange to me. This imply we know all languages that
will be included in the near future or include ALL languages that are
spoken on this planet. The "Ethnologue" from 1996 knows 8717 languages,
400 of them are already dead. Then you have a factor for dialects and/or
different regions. This will consume 5 years of Eike,Ivo,Pavel's life to
integrate all known locales, patches , etc... You need several months to
translate those 250000 (?) strings and 4* 15 minutes for patch creation
is to much?
I am sure that we can drop that list two 250-300 languages (i am working
on that list now) and 1/3 of the necessary patches can be almost created
automatically, e.g. include all Microsoft languages IDs patches in
advance etc. KDE has that approach.
Every language needs translation in langtab.src and langpack.ulf . Who
can provide them ?
- Create a good OOo 2.0 glossary including IT terms and definitions
Pavel created a script that filters all words that occur 4 times or more
often in the translation. Does that meet your requirements ? David also
mentioned that they currently test a "poconflict" tool, that detects
different translated words. Is there realy a need for such glossary if
you use a po based translation memory system?
I did the same kind of script and come up with a 1500 word list. The
wordlist is NOT enough. The problem is to provide a good technical
definition of each of terms so translators can UNDERSTAND what they are
translating. An online OOo IT dictionary. Sad enough, Microsoft has one
in their localizations project. Think in: What is Ruby lines? What is
the difference between layout and arrange? etc. That glossary +
definitions does not exist today in OOo.
Youngs idea with a community wiki sounds to me the best solutiuon for this.
Cheers,
Ivo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
