Get localization framework in place and working

Would it be worth writing a GUI tool to make this easier?

Great job on this Ed.

A question I have is: where does localization of a given dabo-based application happen? Where does the application developer put their .mo files so that Dabo will find them and translate the strings at runtime?

I don't think that it has come up yet. I was under the assumption that the localization was just for strings appearing in the framework and if the developer required multiple languages he would have to roll his own system.

However, I think that your question definitely has merit. I think that it would be a nice feature for the framework. I would suggest coding a method that takes a directory path to a locale directory. That way the developer can implement their preferred directory structure. The structure inside the locale directory should mimic the structure of the dabo locale directory.

Some links for localization:

http://www.digitale-wertschoepfung.de/artikel/gettext/gettext.html

http://babel.edgewall.org/

http://www.poedit.net/

http://translate.sourceforge.net/wiki/

dLocalize.py

I did a major rewrite of dLocalize.py, because 1) current version doesn't support localization of user app, only the framework 2) supported localizations are hardcoded 3) there were several bugs

My approach is that as soon as we do "from dLocalize import _" we get the dabo framework localized (locale is taken from environment). From this point we can use localization in framework itself, but non in application yet. If localization for current locale is not available, we just fall back to english. So only english dabo.mo is a must. You can add any other localizations to dabo's localedir

After user application initialization we try also to support its own localizations. They are searched in app's locale directory. Now we have two localizations inplace - translatable string is searched in app's localization (reside under app's locale dir), if not found we try to find it in dabo's localization (reside in dabo's locale dir). So both framework and app are localized with their owns, and both work simultaniously.

good sideffects: 1) we dont' have to translate app's strings if they are already in dabo's localization 2) strings in app's localization override dabo's

current limitations (i will work on them): 1) don't know how to handle situations when either dabo or app is missing its localization. 2) on-the-fly localization's change ? 3) user app's localization is in "app.mo" file, while it should to be in "appname.mo" 4) system wide locale directories are not searched

following is the quick check, that i did and it worked :)

from dLocalize import _ #framework itself is localized at this moment #so we can have diagnostik messages of framework to be localized

import dabo

# but application is still not !

app = dabo.dApp()

app.setup()

# now we can have app's localization

print _('application localization test') # works here, russian string is printed

form = dabo.ui.dForm(app.MainForm?, Caption=_("Hello!")) # works here, windows' title is in russian

tb = form.addObject(dabo.ui.dTextBox, "tbox")

tb.Value = "Cool stuff!" # But if i try here, i get an error: UnicodeDecodeError?: 'ascii' codec can't decode byte 0xcf # in position 13: ordinal not in range(128)

form.tbox.FontBold? = True

form.Visible = True

app.start()

Great, thanks! I'm going to let Ed review this, since he's done most of the localization stuff. +1 from me, though, from the looks of it.

Oops, please convert to tab indentation and resubmit. Also, it would be great if you would be consistent:

__localedir = "locale"
__dabo_trans=None

We like a space before and after the = in assignments, like you did localedir.

Thanks! :)

tried to deal with tabs/spaces, some comments, some kind of testing

From http://babel.edgewall.org/

Babel
A collection of tools for internationalizing Python applications

Babel is composed of two major parts:

    * tools to build and work with gettext message catalogs
    * a Python interface to the CLDR (Common Locale Data Repository), providing access to various locale display names, localized number and date formatting, etc. 

paul's version

I took dLocalize.2.py, and modified it to not require the app's locale structure to be set up, and to take into account my changes from last night that make it work in frozen apps. Please review on your end and let me know if it still works for you.

Thanks!

Now it works as expected: user app's localization is used, if it actually exist I performed some tests - works for me

Don't know what to do with that hack, overcoming python string 7-bitness

See dabo revision [3286] - I believe we just about have this licked. Thanks, Nizamov!

I think that overcoming the default ascii encoding should be left to the user/application developer. But yes, we should document it somewhere, perhaps in the FAQ?

Small typo in dLocalize.py / getLocaleDir: there's once "localeDir" (uppercase D) that leads to "NameError?: global name 'localeDir' is not defined" with py2app/py2exe.

def getDaboLocaleDir():
	localedir = os.path.join(os.path.split(dabo.__file__)[0], "locale")
	if not os.path.isdir(localedir):
		# Frozen app?
		# First need to find the directory that contains the .exe:
		startupDir = localedir
		while startupDir:
			startupDir = os.path.split(startupDir)[0]
			if os.path.isdir(startupDir):
				break
		localedir = os.path.join(startupDir, "dabo.locale")
	return localedir

Fixed in [3411]. Thanks!