This has been fixed in CVS. thanks, though.

It has?  This appears to be different from previous intl charset
problems because it involves ISO-8859-2 chars rather than ISO-8859-1
chars.

I suspect it works fine with gnomecard et al. because 

I suspect they used windows codepage 1250, central european, (rather
than 1252) as the basis for the pilot character set.

I checked it with the last snapshot [cvs.2001.11.05.15.31] - still the
same problem.

Actually, the GNU-czech Palm localization
(http://www.redgrep.cz/GNU-czech/cestina-0.71.zip) offers three possible
codings: CP-1250, ISO-8859-2 and Mac. I use the 8859-2 one. Perhaps
Gnomecard works exactly because the character mapping Palm<->desktop
is identical?
I think it would be neat if the coding used in Palm could be specified
in conduit configuration.

Yes, it probably works with gnomecard for the reason you specified.  I
need to write some locale detection code for pilot link (there is a
system info setting that contains a locale code).  Can't do this for
1.0, but it needs to be done soon, marking as 1.0.x

*** bug 215878 has been marked as a duplicate of this bug. ***

you're close to a patch for this, right, jp?

Not sure why this was wishlist.

Probably because I forgot to change the default setting in the
Bugzilla form. Sorry.

I'm not sure I can fix this problem in time for 1.0.1.  I'll try but
it may be a 1.0.x bug.

Not going to make 1.0.1

FWIW, if you re-compiled the pilot-link rpms with the charset changed
in one define you could probably get it to work.

*** bug 223663 has been marked as a duplicate of this bug. ***

I'm unable to find any documentation stating that the palm officially
supports the Latin-2 encoding.  Is it only supported by putting this
downloadable .prc file on the device?

Actually, a complete Czech localization of PalmOS (closed source) is
also available. I'm not using it but it supports Win-1250, ISO-8859-2
and Mac encodings.

I see.  Does that require a minimum PalmOS version?  Where can i
obtain it for testing?

The Czech localization is available for PalmOS 3.5 and 4.0. It is a
commercial product of the RedGrep company (see
http://www.redgrep.cz/products/) and can be purchased for 980 CZK
(about $30). However, for the conduit testing the free GNU Czech
package should be sufficient IMHO. It provides necessary fonts and
enables graffiti input of accented letters and is available also from
the above web page. You need version 0.74 for PalmOS 4.0 and 0.71 for
PalmOS 3.5. The sources (Zdrojáky) are also available. As the
installation instructions are in Czech, I can provide you necessary
translations if you want.

*** bug 216976 has been marked as a duplicate of this bug. ***

*** bug 216316 has been marked as a duplicate of this bug. ***

for what it's worth, e_iconv_charset_name() can be used to figure out
what charset the user's locale is. although with all the distro's
moving to UTF-8, this won't be as useful in the future.

er, e-iconv.h is part of gal. might not be able to use it... tho you
might be able to copy the code?

Hungarian text synchronization is also broken. (Evolution 1.4.4,
Debian i386 Unstable)

Note, that the Hungarian language supports only two (pair of)
characters, which is not in the ISO-8859-1: o with double acute and u
with double acute. (and the upper-cased pairs of them). The others are
all supported.

I am using a Handspring Treo 180 with GPRS patch 1.2, which has PalmOS
3.5.2H installed, and PiLoC for the Hungarian localization. The
Hungarian localization is adjustable, I can set "Win" or "Iso"
character sets (I also can set "Mac+", but it is unusable). I did not
find any difference between the two setup, so I left it in "Iso".

When I add an event in JPilot (In JPilot I set the character
conversion to "Latin1/no conversion"), it is synchronized to the palm
and can be viewed perfectly (with the hungarian accents also). It
works well even if I add the event in Treo first, then synchronizing.
It also works if I edit the events and sync them back, etc.

But with evolution, the hungarian accented text become confused.

To reproduce the problem:

(I don't know how the ő character is shown in this bug-report, so I
will use o" instead of the "o with double acute" and u" instead of "u
with double ocute" to make sure everything can be seen).

1. Add a calendar event in the pilot, which has the name: Anythingu"o"
(other fields are not important).
2. Do the sync.
3. You will see the new event in the calendar: Anythingo~u^, so
evolution used the iso-8859-1 character set, not iso-8859-2, although
I set LC_CTYPE to "hu_HU" (all other locale variables are set to "C").
4. Edit the event name to Anythingu"o" in evolution
5. Do a Sync
6. You will see that the event name is changed to Anythingőű (it
seems that evolution converted the name to UTF8 and Palm tries to show
it in ISO 8859-2).

I suggest that the user can set the character set of his PDA (in
gnome-pilot) if evolution cannot query it.

The synchronization should convert the entries from both side to
unicode and then convert back to the evolution and PalmOS-specific
locale when modified.

Idea?

*** bug 267876 has been marked as a duplicate of this bug. ***

Hi,

I've been experiensing the same problem with all versions of
evolution. I'm currently using evolution-2.0.2-3, which ships with
Fedora Core 3.

I'm using Piloc to be able to write greek in my palm. Synchronisation
with JPilot & windows works great. With evolution, however, all i get
is  the wrong glyphs. Must be an issue with the encoding.

Here's an example
http://www.rohirrim.org/evo.jpg

The Full Name: entry shows correctly as greek in the palm, but not in
evolution.

Note, that as the image shows (the Job Title: field was typed in
evolution), I can correctly read/write greek on my system with evolution.

Is anyone still working on this bug? Any chance of a resolution? It's
very frustrating for us international users.

Any help would be appreciated.

Thanks, all, for a wonderful product!

*** bug 247038 has been marked as a duplicate of this bug. ***

*** Bug 260466 has been marked as a duplicate of this bug. ***

retargetting from 2.1 to 2.3, reassigning to varadhan.

(i really should do what i'm commenting)

*** Bug 317834 has been marked as a duplicate of this bug. ***

I am experiencing this problem with Evolution 2.4.1.
I am using a Treo 600 palmtop with PiLoc Hungarian and ISO8859-2 character set.

When I enter an o"  (o with double acute) on the Treo and sync I get it mostly right in Evolution (although not exactly the same character, it is an o with an ~ on top of it).
BUT
When I enter an o" in Evolution and sync it to the Treo, some weird characters appear. It must be some encoding mismatch problem.

It would be nice to have this one corrected because otherwise Evo cannot match the sync functionality of Outlook on Windows.

I second the suggestion that the user should be allowed to enter what codepage is used on the palmtop.

(In reply to comment #30)
> I am experiencing this problem with Evolution 2.4.1.
> I am using a Treo 600 palmtop with PiLoc Hungarian and ISO8859-2 character set.

I have the same problem with Evolution 2.4.2 and using old Palm Pilot Pro where localization software runs using cp1250 encoding.

Without it, Evo's syncing feature is of not much use to non-English users, so I propose that some preferences is added (simialr to JPilot & KPilot - both applications sync properly), so that users can choose encodings on PDA side, e.g. iso8859-2, cp1250, etc.

Sincerely,
Gour

Charset conversion is not implemented in Evo. It's made inside pilot-link library. Unfortunately the pilot's charset there is hardcoded. I've just sent them a patch that, with a byte of luck, could get into pilot-link 0.12.4. It will allow to configure the charset with PILOT_CHARSET environment variable.

Created attachment 63849 [details] [review]
Patch for pilot-link 0.11.8 (fits also for 0.12.0pre4)

Since I haven't had any hearing from pilot-link guys I decided to post this patch here. I've checked it and it handles my latin2 entries well. I'dont know, however, what will happen when an entry contains characters that are out of pilot charset.

How it works? Simply put:

export PILOT_CHARSET=latin2 #or any other charset name acceptable by iconv

in you: .profile, .xprofile, or any other place that will assure that conduits will see this variable. Gpilot or conduits, though, could set it everytime the run according to some UI preference box.

PS. I've meant 0.12.0 not 0.12.4 above.

retargetting; we have a patch here.

varadhan: *poke*

This issue is addressed by http://bugs.pilot-link.org/1335. The request is almost two years old, there's little chance it ever gets fixed.

Hi!

I've emerged gnome-pilot-2.0.14 and gnome-pilot-conduits-2.0.14 and patched them with memory-leak patch - http://bugzilla.gnome.org/show_bug.cgi?id=357602.

Then I patched evolution with pilot-link-0.12.x API patch from http://mail.gnome.org/archives/evolution-patches/2006-August/msg00083.html.

Added the following line in my ~.bashrc:

export PILOT_CHARSET=CP1250, restarted my machine and now Evo-2.8.1 is syncing with my cp1250 Palm Pilot :-)

Perfect! No more mess on my Pilot ;)

This bug can be closed, as far as I'm concerned.

Sincerely,
Gour

Have you tried using CP1250 in category names? How does it work?

Hi!

Good question...no, it does not work in category names.

Generally speaking, there is no sync between pilot's categories and the ones in Evo.

Sincerely,
Gour

Attached patch is for pilot-link and hence closing it as NOTGNOME.  Support for pilot-link 0.12.x has already been committed to trunk.