[Bf-committers] Internationalization (i18n) and blender state of affairs...

Kent Mein mein at cs.umn.edu
Thu Nov 19 17:25:34 CET 2009

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
	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:
	c examples:
	The manual for gettext:  

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 

	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 

	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.

mein at cs.umn.edu

More information about the Bf-committers mailing list