Re: Grip and i18n

Hi all!  :)
Excuse me for my so called English, but sf is a place, where people "speak" programming languages, right?
There I will explain my experience with my own written patches:

1. Patch #1004959 is addition to support a non UTF-8 encoded local DB entries. Such entries were produced by many other programs and some old versions of Grip too. If it detects whether the entry is not UTF-8 encoded, then converts the entry from the
chosen by the settings encoding (or if UTF-8 from ISO-8859-1) to UTF-8. Otherwise, if Grip trying to read such entry, and then passes the UTF-8 incompatible characters to pango, error messages and empty text widgets occurs.

2. Patch #1004963 prevents UTF-8 multi byte characters to be splited by two consecutive lines. Otherwise, _every_time_ where such situation occurs while sending update to database, freedb rejects the entry.

3. Patch #1004952 exchanges the charset conversion to skip incompatible characters, instead of leaving it wrong encoded.

4. Patch #1003484 concerns to the DB receptions and submissions. It allows CDDB protocol level 6 (where data transmission is only in UTF-8), only if both UTF-8 and "freedb extensions" are present on the DB settings. In freedb database are many erroneously
non UTF-8 and non ISO-8859-1 encoded entries. That patch allow using them, causing freedb to send it as is, instead of performing a ISO-8859-1 to UTF-8 conversion. The patch also assuming that if "freedb extensions" are present, submitting will be only
in UTF-8, as the CDDB protocol level 6 said: "only ISO-8859-1 or UTF-8". When taking a look at the cddbd's source code we perceive, that it tests (if present) the e-mail header and if non ISO-8859-1 or UTF-8 is announced, then rejects the entry. Other
way is to test that.

5. Grip by now uses two different conversions for filenames, and when G_FILENAME_ENCODING and locale charset (by default UTF-8, but can be changed) differs it is possible to fail ripping. It first creates directories and .m3u names using
g_filename_from_utf8(). Afterwards it tries to rip and encode using g_locale_from_utf8(). If filename and locale charsets are different and one or both conversions succeed, then ripping and encoding fails because of missing locale encoded directories.
After that, in .mp3 case, if ID3 settings are present, Grip (successful) tags the missing .mp3 files, producing ".mp3" files with only tags but not MP3 inside. Patch #1003525 fixes the bug. Other thing are changes (almost replacement at all) in
MungeString() to allow non ISO-8859-1 and non UTF-8 charsets. Now characters are converted one by one using g_filename_from_utf8(), and on success they are appended to output. Optional hex dumping is added for incompatible characters .

Maybe, there is still possible to "eat" parts of ending multi byte chars in ID3v1 tags, producing incompatible strings, when using multi byte charsets, but I have not tested and not patched that (I am not using ID3v1). Such junk may occur anywhere because
of the Grip's fixed string sizes while overflowing them. I have tested and used them, trying mixes of different alphabets and changing an encoding, but I have not information whether anybody has tested too.
________________________________________________________________________________
Other my useful and also tested by me patches are:
- #1013403, fixing ID3v1 zero marker overwriting;
- #1004972, fixing the white space text data losses, discussed over Internet.
________________________________________________________________________________
Unicode support:
Patch #1003578 works fine, but requires patches #1073951 and #1015188 to be applied on id3lib. I suggest, as ID3v2 standard told what encodings are allowed, to disable non ISO-8859-1 encodings on ID3v2, as using them violates the standard, while id3lib
team releases a version with useful C wrappers.
________________________________________________________________________________
At the end I send an attached file containing new Bulgarian translation update together with some of the above mentioned patches.
________________________________________________________________________________




--------------------------------------
Òîâà ïèñìî å èçïðàòåíî îò  www.mail.bg

Áåçïëàòíàòà ïîùà â mail.bg ïðåäëàãà:
- Ñèëíà çàùèòà ñðåùó ÑÏÀÌ/ðåêëàìíè ïèñìà
- 30MB áåçïëàòíî (SMS îò 2ëâ=3GB!)
- 30MB ìàêñ. ðàçìåð íà ïðèêà÷åí ôàéë
- SMS çà íîâî ïèñìî (âñè÷êè îïåðàòîðè)
- WAP äîñòúï îò GSM è áåç êîìïþòúð
- Áåçïëàòåí POP3 äîñòúï
- 24 ÷àñîâ òåëåôîí çà ïîìîù/ïîääðúæêà
______________________________________
ÁÅÇ ÈÇËÈØÍÈ ÂÚÏÐÎÑÈ ÐÅÃÈÑÒÐÈÐÀÉÒÅ ÑÂÎÉ
ÁÅÇÏËÀÒÅÍ ÀÄÐÅÑ ÍÀ  http://www.mail.bg