Discussion: translating Puppys System-tools

For efforts in internationalising Puppy and solving problems in this area
Message
Author
User avatar
nyu
Posts: 110
Joined: Tue 14 Mar 2006, 15:30
Location: good earth

#31 Post by nyu »

GuestToo wrote:

and locale -a seems to show that you have a zh_TW.UTF-8 locale

do you get any error messages if you start dillo in an rxvt console?

and of course, you are using the internationalised dillo and not the standard version?
When I run dillo in an rxvt console, I got the following errors but I am not sure they are related to my problem:

debianinstallerrc :38: unexpected string constant "send", expected symbol
debianinstallerrc :38: unexpected string constant "referer", expected symbol

And yes, I am using MU's dotpup Dillo file.

GuestToo
Puppy Master
Posts: 4083
Joined: Wed 04 May 2005, 18:11

#32 Post by GuestToo »

that is strange ... i do not know why dillo would be accessing a file called debianinstallerrc ... i do not have that file, i just unzipped MU's package and copied the files to the appropriate places, i try to avoid registering things with pupget, and i did not want the package to mess with my menus either ... i try to make my own packages so that they are as independent of Puppy as possible

it seems that your locale is working, or there would be an error message "locale set to C"

maybe the locale is using the wrong character set ... as i said, i do not know a lot localisation

User avatar
nyu
Posts: 110
Joined: Tue 14 Mar 2006, 15:30
Location: good earth

#33 Post by nyu »

GuestToo wrote:that is strange ... i do not know why dillo would be accessing a file called debianinstallerrc ... i do not have that file, i just unzipped MU's package and copied the files to the appropriate places, i try to avoid registering things with pupget, and i did not want the package to mess with my menus either ... i try to make my own packages so that they are as independent of Puppy as possible

it seems that your locale is working, or there would be an error message "locale set to C"

maybe the locale is using the wrong character set ... as i said, i do not know a lot localisation
I need to spend some more time to find out what is going on......

User avatar
MU
Posts: 13649
Joined: Wed 24 Aug 2005, 16:52
Location: Karlsruhe, Germany
Contact:

#34 Post by MU »

Dillo is based on Gtk1.
Gtk1 cannot display Unicode as far as I know.

So Dillo will not be able to display chinese in the menus and option-dialogs.
The next release of Dillo will be based on Fltk, maybe that can display unicode.

Mark

User avatar
Nathan F
Posts: 1764
Joined: Wed 08 Jun 2005, 14:45
Location: Wadsworth, OH (occasionally home)
Contact:

#35 Post by Nathan F »

This is something I will look into (FLTK + unicode) but right off my guess would be that unicode will be supported. Dillo is not the only major project porting over to FLTK, Cinepaint is doing so as well. I have to assume the developers at least took this into consideration.

If my memory serves I did read about it once, and the reply given was that unicode will be supported by FLTK but that support is not fully complete yet. Like I said, I'll research it.

Nathan
Bring on the locusts ...

User avatar
nyu
Posts: 110
Joined: Tue 14 Mar 2006, 15:30
Location: good earth

#36 Post by nyu »

Thanks, I am learning more and more. There are many software
packages in Puppy which can't display Chinese. I want to know why.
Basically because they were written in gtk 1.x? I brought up Dillo because
it is the internal web browser for Puppy. It will be nice to display menus
and option-dialogs in Chinese. More and easier localization of Puppy will
spread Puppy to China, Taiwan, Hong Kong and oversea Chinese :lol:
I am just wondering why the following Dillo setup page can display Japanese.
http://teki.jpn.ph/pc/software/dillo-cfg-i18n.png
Are they using other than Unicode? I also have tried a Knoppix Chinese
distribution which uses zh_TW.Big5 as the locale. It can display menus
and option-dialogs in Traditional Chinese. Searching google gave me some
information of how to make a file in /etc/gtk to deal with gtk 1.x and Unicode.
But I have tried in Puppy without success. I am stuck. If some more
knowledgale people in this community can give me hands, I will be really
appreciated it.
Thanks again,
nyu

User avatar
MU
Posts: 13649
Joined: Wed 24 Aug 2005, 16:52
Location: Karlsruhe, Germany
Contact:

#37 Post by MU »

nyu, I have no idea...
I think Gtk itself might have to be compiled with UTF8-support?
Maybe Barry deactivated it?

maybe at http://gtk.org some hints can be found.

I know from wxWidgets (that uses Gtk), that the Utf8-feature in version 2.6 was very difficult to compile, one reason why wxBasic still uses the older wxWidgets 2.4.

User avatar
Nathan F
Posts: 1764
Joined: Wed 08 Jun 2005, 14:45
Location: Wadsworth, OH (occasionally home)
Contact:

#38 Post by Nathan F »

I haven't tried it but this seems on target:
GTK 1.x method

XMMS use GTK 1.x and sometimes don't display utf-8. this is a little tweak. Just define a gtk1 font for the your user by creating (or editing) ~/.gtkrc:

Type "nano ~/.gtkrc" and put the following into the file.

Code: Select all

style "user-font"
      fontset = "-misc-fixed-*-*-*-*-12-*-*-*-*-*-iso10646-1"
       
widget_class "*" style "user-font"
From some gentoo documentation on enabling unicode, this is a GTK-1.x section. It mentions XMMS but hopefully the same applies to other GTK-1 apps as well.

Nathan
Bring on the locusts ...

User avatar
nyu
Posts: 110
Joined: Tue 14 Mar 2006, 15:30
Location: good earth

#39 Post by nyu »

I have tried it but it didn't work for me.

User avatar
nyu
Posts: 110
Joined: Tue 14 Mar 2006, 15:30
Location: good earth

#40 Post by nyu »

MU wrote:nyu, I have no idea...
I think Gtk itself might have to be compiled with UTF8-support?
Maybe Barry deactivated it?

maybe at http://gtk.org some hints can be found.

I know from wxWidgets (that uses Gtk), that the Utf8-feature in version 2.6 was very difficult to compile, one reason why wxBasic still uses the older wxWidgets 2.4.
Since Barry is very interested in the OLPC project, he should be more aware of Internationalization and localization of Puppy. I assume most of these laptops
will be end up to developing countries :oops:
nyu

User avatar
Nathan F
Posts: 1764
Joined: Wed 08 Jun 2005, 14:45
Location: Wadsworth, OH (occasionally home)
Contact:

#41 Post by Nathan F »

Good point, but let's approach that with some tact.

Nathan
Bring on the locusts ...

sin
Posts: 23
Joined: Tue 11 Apr 2006, 09:03

Some thoughts

#42 Post by sin »

I just want to propose an approach to simplify Puppy scripts and wizards internationalization.

There is an approach without MU's 1'st step (Replace each word with a variable): every localizable piece of text is left in place in english but passed as a peremeter to translating function t(). t() is trivial when locale (or other variable) set to english, and returns appropriate translation in other case.

Similar thing is used in Drupal CMS for localization. Actual translated pieces of code are stored in database (we can use SQLLite) and exported/imported using .po files. We can replace database with a gettext library to work with po and mo without database.

The advantage of this approach is tiny the ammount of effort from developers of scripts and wizards -- no need to insert constants, just add t() function calls. English po files for translations are created automatically from script/wizard by a perl or php script (we can use Drupal's extract.php).

The disadvantage is speed and duplication (we can't throw out english from localized version, it wasetes space cause it is built into sources).

sin
Posts: 23
Joined: Tue 11 Apr 2006, 09:03

#43 Post by sin »

GuestToo alredy tested proposed approach, I just found his gettext translating program - demo 2 topic. Just "eval_gettext" instead of "t".

JohnMc
Posts: 118
Joined: Fri 07 Apr 2006, 15:18

Localization

#44 Post by JohnMc »

I would like to get back to Kingskid's remark on getting the translations done. If the developers can settle on the approach (ie gettext, or?) and provide the necessary translation file & format some of us lesser mortals could do translations.

And I'll put the stake in the ground right now -- I'll sign my family up for the Russian translation.

GuestToo
Puppy Master
Posts: 4083
Joined: Wed 04 May 2005, 18:11

#45 Post by GuestToo »

my dotpup handler script in Puppy 210 and 211 uses gettext for translation ... there are only 2 translations so far, de and fr

the trouble is, i used xmessage/gxmessage to display the messages ... xmessage is small and simple ... xmessage is a gtk1 app, so it does not display unicode properly ... gxmessage is a gtk2 app, and can display unicode characters

so i have to think about what to do ... gxmessage is small, 21k (11k if compressed with UPX), but it is not included in the standard Puppy iso

i could rewrite the handler script so that it uses another program to display messages that will support UFT8

or i could make sure gxmessage is installed when translations are installed, and if gxmessage is not available to force en messages

the handler script is really just the first alpha version of an experiment using gettext, but since the older script supposedly did not work in Puppy 210, the experimental alpha script was put in Puppy 210 ... it seems to work ok, so far, but translations are not fully supported, because of xmessage

i guess it could be rewritten using gtkdialog ... xmessage has a simpler syntax, though ... i like to keep things simple ... maybe a puppybasic wrapper would keep it the script simple ...

oh, and the script has changed since the .po file was made ... the strings are still the same, just the line numbers are a little different

Post Reply