So we have a couple of pending issues with our international support.
I started looking at this before the big 2.5 push, and decided it was
better to wait until we actually knew what was going on with 2.5.
I think were to the point where we can start dealing with this.
I talked to Ideasman and Diego a little bit about this.
Just so everyone is on the same page....
The General process for international support:
Mark what strings you need to translate:
Wrap all strings that you want to translate in _()
Run xgettext on the files. This produces a .pot file, which is
a template for translators, that has all strings that need
translation.
Have translators take a .pot and generation translations, (.po files)
At compile time generate .mo files.
In the code to actually translate stuff you need to set your
locale and call special functions to translate your strings.
You need to then periodically generate your .pot and
update your translation files.(fix .po's and generate new .mo's)
Why Blender is complicated:
Blender is complicated because its a mixture of c/c++ and python,
strings that need to be translated are in both c and python.
Translation occurs in the c portion of the code, and at this
point I'm not sure were translating everything we need to.
We don't have a means to generate a .pot file currently we just
tell people to look at the latest .po file and use that.
We don't have a nice way for people to update/fix their .po because
we don't have a .pot file.
We don't have good documentation on how translators can do all this
stuff. We need to make it simple for them.
If we standardize our gettext support this is simple...
Examples to look at:
Python:
http://www.learningpython.com/2006/12/03/translating-your-pythonpygtk-application/
http://wiki.laptop.org/go/Python_i18n
mailman
c examples:
http://oriya.sarovar.org/docs/gettext_single.html
SDL
The manual for gettext:
http://www.gnu.org/software/gettext/manual/gettext.html
Game plan:
The biggest issue we have is that we have no way to generate an
up to date template(pot file).
Some other issues are when to translate, how does where we translate
affect things.
The standard example assumes your doing everything at once and
is to include some extra headers or import gettext,
set your locale with a query to the system's locale and then wrap
all strings we want to translate with _() (which is an alias for
the function gettext()).
Because of the way the code is structured now with 2.5, and the fact
that we let people choose their locale, we have a slightly different
situation. We have three cases, code that uses the new method,
(example release/scripts/ui/space_sequencer.py), we have
just plain c code with gui stuff in it, and we have rna strings
that need translation.
The python code is the more complicated so lets focus on that.
We can import the standard gettext code, and mark our strings with _()
because of the process though we don't really have a good way to
query what locale we have set, and actually do the translation.
What we probably want to do is just mark the strings we need to
translate, we can do this by making _() a no-op function and
then wrapping appropriate strings with it.
If we need to we can also make a python function to query the locale,
which will enable us to translate earlier if needed.
For readability Ideasman asked if there is a way to do with out the
_(). Because were using common functions in python to declare whats
a gui element, I told him we could probably write our own parser that
would look at the specific functions and pluck out the text parts
that need to be translated. I'm not sure how well this will work.
If it works well then thats a nice option, it will not cover everything,
though so we will have to fall back to _() at a minimum for the c code.
and possibly for special cases in the python code.
We also would not be able to translate earlier if needed if we
go this route...
(I'll look into this, I'm kind of leaning towards the I don't like
this, and would rather have a standard uniform method of doing this,
I'm open to suggestions. I think it makes it harder to maintain
in the long run, and harder to track down issues with the system.
We would have a hard time figuring out which method a string was
suppose to use and might wind up with strings translated
multiple times...)
Once we have all of our strings flagged and can generate our pot
we need to worry about where it does the actual translation,
currently I'm not sure if this is fully working or not. Need to
do some digging into the source code to figure it out. As I
mentioned we have 3 different types of strings we need to translate,
where before we only had c code, now we also have Python and RNA.
We also have an older system and a "new" system for translation
so we need to make sure everything is using the new system...
for now I think we should stick with translating later for
things and put all of the translation calls in our gui routines.
Its probably faster on the c side than in python, and lets us
dynamically change locale, and keeps our python stuff simple.
It's also nice to do it all in one location.
The rest of this message talks about why this might not be possible
and what we need to watch out for in translations. (It's kind of
a hodgepodge of information)
Things to keep in mind:
For good translations, you want as complete of a sentence as you can
get.
If you have something like this:
"The Translation %x,%y,%z scaled by %f will be applied to
Object: %s"
This may not translate well if you break it into its parts
and try to use the parts separately. I'm not going to list
specifics but if you look at the gettext documentation you can find
great examples.
You also do not want to try and translate the variables, for example
it would be bad to translate an objects name, especially if its used
internally.
This creates a balancing act for us. We want to pass good strings to
the program that generates the pot file. We want to keep the python
scripts simple and readable. We also want to produce good
translations, and we want the code to do it quickly.
--
m...@cs.umn.edu
http://www.cs.umn.edu/~mein
_______________________________________________
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
