Recommended Addon

[Goofy]

hello all

As everyone, I still have encoding problems from time to time. Even if I can avoid most of them by experience, I am very ignorant about ANSI, UTF8 (to which I have a superstitious fervor) and whatsoever weird things
Sometimes I am proud to find the bug and to have spent hours for a "&" in a locale file..
Sometimes I am ashamed of having destroyed the ja-JP locale of a babelZillian friend, just with opening/closing a file with Pspad set for UTF8

So... Some of you seem to know much about that, some others are real hackers, some are dedicated to sorcery code ...

so please post your tricks and tips and knowledge here !

[victory]

this is just a passing idea though..

when we include Japanese characters into *.propaties files,
we should encode those file using native2ascii(or something like this) after edit, before zip.
can't you use this for adding some sentence into multi-byte files?

native2ascii -encoding utf-8 native-file ascii-file
native2ascii --reverse ascii-file native-file

only adding after its content, you can use redirect, of course.


other?
use binary editor for merging your sentence, in conjunction with favorite text editor :-)
try xyzzy :-)

in fact, I edited using binary editor when I edited http://www.bugzilla.org/download/
because that file has numerous characters.

[Luana]

- dear MatrixIsAllOver, I have read frequently your messages about using ANSI, and I never really tried, not that I don't trust you  , but I thought it was compulsory to use utf-8. Can you confirm nothing strange happens for the extension when your locale is in ANSI ? (I suppose it is for the .properties file, what with the contents.rdf and the .dtd ? )
[right][snapback]1737[/snapback][/right]

Dear Goofy,
I can confirm that the following quoted method works really fine

I try to explain better using an Italian example:
In case I have to translate "it will open" I start my translation using UTF8 encoding, therefore I'll write "aprirà", but before saving the file I'll change the encoding to ANSI-> "aprirà "; and this method works fine! 

NOTE: ANSI is 8-BIT, and not UNICODE !!!
E.g.>>In the above example "it will open" using UTF-8 encoding becomes "aprirà", using ANSI-> "aprirà " and using * UNICODE "aprir\u00E0"
* I use UNICODE (& PsPad) when I have to localize properties file!

Naturally, only if you try you may confirm yourself too

Regards

[Goofy]

thank you for explaining, but I am so very goofy as you know, some points remain unclear for me.

1. For .dtd files, I always use PsPad set once and for all on uft8, and no encoding problem ever occurs with our weird characters : I just write " mêmes les élèves garçons mangeront du maïs où ils veulent" save it as it is and have it without problem when the extension runs.
Is it for dtd files that you use ANSI ? (I suspect I did not understand anything once again )

2. For .js and .properties file, I use just the same utf8 setting, BUT (as you know) I cconvert the special characters just before saving with a special file (see attached zip below) that I once and for all have patched in Pspad app folder.
Is it in this case that ANSI can be useful ?

Or else did you mean that the very recent builds of Firefox need to apply ANSI with extensions ?

Help, I am deep in a pretty kettle of fish !

Attached File(s)

 UnicodeEntity.zip ( 686bytes ) Number of downloads: 13

 

[Luana]

Is it for dtd files that you use ANSI ? (I suspect I did not understand anything once again )

Exactly
I use for *dtd files UTF-8 encoding while I translate, but I switch in ANSI encoding when I save the files

For .js and .properties file ANSI can be useful ?

Absolutely no!
I use for these files UNICODE encoding too

Or else did you mean that the very recent builds of Firefox need to apply ANSI with extensions ?

Not "very recent build"...
I use this "method" in order to localize in Italian language every extension which has a compatibility between FF aviary builds (1.0.x) and FF DP alpha1/alpha2 & DP beta1

[Goofy]

smile.gif
I use for *dtd files UTF-8 encoding while I translate, but I switch in ANSI encoding when I save the files

Good, but.. I still cannot figure out WHY you switch to ansi, because utf8 alone is sufficient for me and does not need further trick... What if you do NOT save in Ansi ? Do you have parsing errors ? I don't when leaving utf8 alone ?

Sooooorry for insisting, I must be missing something somewhere and maybe everybody knows but me

[Pedro]

Soooorry for insisting, I must be missing something somewhere and maybe everybody knows but me   

You are not the only one! This discussion is cleaning some doubt that I had about encoding.

[Luana]

What if you do NOT save in Ansi ?

I don't know if this behaviour may be depending 'cause of the different keyboards (I'm not sure at all, but somewhere I read that the French keyboards are various from those Italians [OT]c'est vrai?[/OT]), but if I don't switch in ANSI encoding I notice a XML Error

I think that tittoproject may confirm this strange behaviour

[Goofy]

@Pedro : my previous post and your reaction deleted because they were too irrelevant and - though not intended at all !- may be considered as bad taste humor. Sorry to be goofy.

@Miao I don't know if the keyboard has anything to do with it. Maybe it is the encoding feature chosen on our browser (it is quite possible I write some silly thing here, who cares ). Mine is "Occidental (ISO-8859-1).

If you mean the possibility of accessing to accentuated characters with the keys, it is true that my french (?) keyboard has éèçàù, the double point as appearing on ï and the special accent like on this ê or î, û, ô .
Is there anything like that on an "italian" keyboard ?

[Luana]

If you mean the possibility of accessing to accentuated characters with the keys, it is true that my french (?) keyboard has éèçàù, the double point as appearing on ï and the special accent like on this ê or î, û, ô .
Is there anything like that on an "italian" keyboard ?
[right][snapback]1785[/snapback][/right]

No, in the Italian keyboard we don't have ç, ï ,ê, î, û and ô
* * *
And I don't think that this strange behaviour UTF-8 - ANSI may be depending on the browser encoding, 'cause I use the same your one, and I suppose tittoproject is using the same one too

[Goofy]

No, in the Italian keyboard we don't have ç, ï ,ê, î, û and ô

Oh yes, I am too silly, should have known that, considering you have no words with these characters !

* * *

And I don't think that this strange behaviour UTF-8 - ANSI may be depending on the browser encoding, 'cause I use the same your one, and I suppose tittoproject is using the same one too

Oh. I am pleased to see we have a common ground (in spite of various keyboard designs )

To get back to serious matters (which is pretty difficult these times, I reckon), I still don't understand why I should switch to ANSI. Has it anything to do with the selected OS on my pspad customized features (Format menu) ? Mine is always set to DOS and not to UNIX.

[Goofy]

we don't have ç, ï ,ê, î, û and ô

But how did you write on this very post ? copy/paste ?

- anything about os selecting in pspad ? (seems another goofy ideas of mine )

[xavivars]

I'm not sure, but maybe MIAO has to change the encoding to ANSI because the editor doesn't save UTF-8 correctly. So changing the encoding, he forces the editor to save with that encoding (look that just before saving the text file, character à is viewed like aprirà , what is the same as if you see an UTF-8 file with a non-UTF-8 editor.

Another thing is that I never save .properties files with "escaped Unicode", I always do it with UTF-8, and I haven't had any problem. Could someone explain me why?

[Goofy]

I never save .properties files with "escaped Unicode", I always do it with UTF-8, and I haven't had any problem. Could someone explain me why?

I am unable to explain this other mystery. It must depend of the editor's configuration you are using.

I'm not sure, but maybe MIAO has to change the encoding to ANSI because the editor doesn't save UTF-8 correctly. So changing the encoding, he forces the editor to save with that encoding (look that just before saving the text file, character à is viewed like aprirà , what is the same as if you see an UTF-8 file with a non-UTF-8 editor.

I see, it is very likely. The strange point for me is : that forced encoding (that I must use for .properties or .js files) is useless for me with the dtd files / but it is necessary for Miao and tittoproject when using the same editor (pspad) as me. (I am just wondering what different settings we have, but of course I have not the smallest doubt about the efficiency of the ansi encoding as described above)

[Ptit Lutin]

Axel Hecht, l10n coordinator, has the same trouble than us:

http://www.axel-hecht.de/blog/archives/000190.html

According to Java spec, the right encoding of property-files should be ISO 8859-1 but Mozilla supports UTF-8 too.

[Sil]

According to Java spec, the right encoding of property-files should be ISO 8859-1 but Mozilla supports UTF-8 too.
[right][snapback]2240[/snapback][/right]

I think it's better (or at least much easier) to work with a file that is entirely in escaped Unicode than with a file in ISO-8859-1 encoding mixed with some characters in escaped Unicode (for those characters that don't exist in ISO-8859-1). For example, in Hungarian there are characters like ő and ű (o and u with 2 strokes on them) that have no equivalents in ISO-8859-1 unlike the other special Hungarian characters (á, é, í, ó, ö, ú and ü). If I save the .properties files in escaped Unicode, I won't have any encoding issues and don't have to worry about the accents. But those who use a Western European language don't even meet the difficulties that a mixed encoding would represent (and I think that's why it's suggested this way in the specifications), because the ISO-8859-1 encoding was tailored specifically for them.

BTW, when I started translating extensions, I didn't know much about encodings, I simply followed the instructions at mozdev.org. (And even today I'm using UniRed for editing, because that's what I'm used to.)

[victory]

differs from latin-derivative-language,
Japanese(of course Chinese and Korean also I think) charcters are completely differece so we cannot edit in 'escaped Unicode' format.
as I said above, we use native2ascii to transform them after edit has finished.
I hate this so I'm using semi-automation script to avoid this step though.
anyway, latin chars go through asis, so author's editor should be able to handle at least latin chars correctly :-p

additionary, authors who don't have public repository(real repository, or web-based) should provide diffs between previous version and recent version :-p
my work go using svn so I can see diffs anyway though :-)

[victory]

try this
http://www.omegat.org/omegat/omegat.html