And here’s another “minor”, yet massively requested update, and it’s been added to the desktop and pocket version: HTML encoding. Sadly this doesn’t seem to work for all language, but it will enable me to support non-English Latin-based languages. For more information, click more, to read the rest of this post.
Read: SharpMT FAQ
Read: Pocket SharpMT FAQ
Screenshots: 1 | 2 | 3
This entire issue is caused by MT and their support of non-English languages (or lack there of) through their XML-RPC interface. If it would allow me to send in posts using UTF-8, then even double-byte characters would be supported and everything would be easy… for example, I can save UTF-8 text files with Japanese characters in them: they come back when the file is re-opened. The problem is that when I try to send a Japanese text string (or anything that is encoded as UTF-8 for that matter) to the MT server, the XML-RPC functions yell at me.
So, there’s a workaround that’s been floating around out there, and it focuses on Latin-based languages. Take for example: “déjà vu”. With version 2.3, this would be “d?j? vu” or “d j vu” but with 2.4 it actually goes into the server as “déjà vu” which is completely valid HTML text. Characters that previously weren’t supported by SharpMT are now encoded just before they are sent to the server when posting or editing drafts – Geeks will see this as ASCII codes 160 to 255. Drafts are stored in UTF-8 format, so you will not see the &#nnn; encoding when editing drafts. You will see them when you get information from from the server: if you edit server based entries that are already on the server, you will see the encoded characters but you can type over them without worry because things are encoded when they go back up to the server. I tried this with some Japanese text, but MT didn’t seem to like it, but it might work… if it does or doesn’t, please drop me a comment: it might be because my configuration isn’t double-byte friendly or it might not be supported at all… I don’t know, but I’m hopeful.