Discussion:
[BitPim-devel] BitPim in non-English speaking countries
Константин Семёнов
2006-12-14 23:16:23 UTC
Permalink
Hello everybody!

I'm from Moscow, Russia. I would like to contribute to the project. I
have experience of programming in Python. The software I wrote in
Python was to do with websites, e-mail, parsing and databases. Though,
most of my programming experience over the past 15 years was with
C/Pascal/Delphi.

We have a decent CDMA-450 network in the country, though it is not
very dense (about 200k subscribers currently). Since the 450MHz
standard is relatively new, there aren't many handsets - about 17 for
Russia, in fact. Most of the manufacturers are never heard of in the
US, such as Ubiquam, Huawei or AnyData. The only brand present in the
US is Kyocera, but unfortunately BitPim does not support it. Most of
the handsets don't have any PCSync software. The only decent piece of
software I have seen is provided by Pantech-Curitel.

I own several handsets, which lack the PCSync software, have cables,
and are readable via FileSystem view in BitPim. I would like to start
coding for them straight away, but still, I've got some questions
left:

1) Is it possible (or planned) for BitPim to manage Unicode in
phonebook, calendar, SMS etc? e.g. Google calendar import has shown
squiggles instead of Russian letters, but a manual entry was OK.

2) Is there a way to define LSB Unicode datatype in the packets? Not
to say that I could have changed each p_*.py file to swap the bytes or
to decode/encode the characters from/to a specified charset (there are
at least two different charsets in Russia), if necessary.

3) Is it possible to add an interface translation for Russian? I will
provide all the necessary translations. Probably, a support of
additional languages (e.g. Chinese, Vietnamese, Portuguese) could be
built in.

4) In case when I don't have a common class for a manufacturer, does
the chipset model usually help with finding out the commands (e.g.
finding a supported phone with the same chipset and trying to use it's
commands)? Or is the command set usually common between the phones of
the same manufacturer?

Thank you very much for sharing your precious time.

Kind regards,

Konstantin Semenov.
Roger Binns
2006-12-15 07:26:37 UTC
Permalink
Константин Семёнов wrote:
| The software I wrote in
| Python was to do with websites, e-mail, parsing and databases.

Ironically a lot of the BitPim code is similar (eg parts of the UI use
HTML, there is a database behind the scenes, calendars and SMS aren't
substantially different than email, and accessing external data and the
phones is a parsing issue).

| The only brand present in the
| US is Kyocera, but unfortunately BitPim does not support it.

I don't think they sell very much. Verizon Wireless has 1 Kyocera
phone. Sprint has none. The other small CDMA carriers have several
more, but their market share is tiny.

| The only decent piece of
| software I have seen is provided by Pantech-Curitel.

They provided some of the handset designs used by Audiovox, since
purchased by UT Starcom.


| I own several handsets, which lack the PCSync software, have cables,
| and are readable via FileSystem view in BitPim.

The filesystem view depends on a diagnostics mode present in Qualcomm
chipsets. You should read this page:

~ http://bitpim.org/papers/phonespecs/

| 1) Is it possible (or planned) for BitPim to manage Unicode in
| phonebook, calendar, SMS etc?

BitPim already operates in Unicode everywhere internally. The database
used (SQLite) only supports Unicode text. You have to use the Unicode
version of wxPython.

| e.g. Google calendar import has shown
| squiggles instead of Russian letters, but a manual entry was OK.

Chances are the code that does the import didn't correctly deal with
character sets. Data on the phones as well as external services is in
random other encodings. Usually the sample data we have is all in ASCII
so there isn't an easy way to work out how non-ASCII data is dealt with.

| 2) Is there a way to define LSB Unicode datatype in the packets?

Yes. Does the data need to be 16 bit aligned?

Look for the USTRING type in prototypes.py.

| Not
| to say that I could have changed each p_*.py file to swap the bytes or
| to decode/encode the characters from/to a specified charset (there are
| at least two different charsets in Russia), if necessary.

Usually a particular model on a particular carrier has exactly one
charset so the code just says to use that.

Read dev-doc/packetdescription.txt. You can pass parameters to a packet
(type 'P' which can then be paramaters to USTRING) which would let you
dynamically specificy the charset.

| 3) Is it possible to add an interface translation for Russian? I will
| provide all the necessary translations. Probably, a support of
| additional languages (e.g. Chinese, Vietnamese, Portuguese) could be
| built in.

BitPim currently has zero support for i18n or l10n. I was trying to use
a convention of using double quotes around human strings and single
quotes around machine strings, but it wasn't too strictly followed.

I'm happy to go down the road of putting in the GNU gettext system. It
isn't perfect as a i18n system, but is certainly good enough. The
general steps for a wxPython application are outlined at:

~ http://wiki.wxpython.org/index.cgi/Internationalization

Or do you have a alternative mechanism you prefer?

Incidentally the reason for an all English interface was purely
pragmatic. You can't really claim i18n until you are on the 3rd
translation. Since only US phones are supported, it was pointless.
(Actually there is also a lot of Spanish and my phone supports Spanish
accented characters, but I have no way of entering them.)

Also some of the English is actually British English as I am a Brit.
When I worked in the UK, we had to use US English in all of our
products. This is my petty little way of striking back :-)

The help text is also entirely English. We did have plans to put it all
into MediaWiki (and have a test one setup) and then build the shipped
text from the wiki. I've not seen a good way of doing this yet. There
are various issues such as using namespaces for the content, but you
can't simultaneously use a namespace for the language and for the help text.

| 4) In case when I don't have a common class for a manufacturer, does
| the chipset model usually help with finding out the commands (e.g.
| finding a supported phone with the same chipset and trying to use it's
| commands)? Or is the command set usually common between the phones of
| the same manufacturer?

The filesystem commands are common across all Qualcomm chipsets although
they have gone through a few versions. The other commands are usually
common to a manufacturer (eg phonebook). However field sizes differ
across models. The location of information varies by model, and often
by carrier (eg where camera photos are placed). There are also two
different standards for embedded phone apps. Some carriers use J2ME
while others use Brew, and that also causes different layout.
Additionally the largest CDMA carrier (Verizon Wireless) is moving to a
model where they supply the UI running on the phone, not the handset
manufacturer.

Roger

Loading...