Xinha Discussion Forum

You must use the PHP backend with the downloaded copy of aspell, aditionally, you'll probably have to adjust stuff to your host.  I don't much like your chances getting it running with Globat though, I don't know if they allow calling custom executables from PHP.

We'l be leaving it with PH for three reasons...
1. keeping it neutral, if a Xinha user/developer hosts it then it could get difficult if they lose interest
2. PH knows what they are doing with Trac and SQLite - I know what I'm doing most of the time, but was completely unsuccessful in keeping trac running smoothly
3. We already moved there :)

All javascript strings are internally representad as unicode data anyway (in the javascript engine), the encoding (utf-8) is only for getting strings "into" javascript strings, and "out of" them if necessary.  Once inside the string variable (object) they are just plain old Unicode without any encoding.

I think that we should use UTF-8 only for language files, translators can convert to/from thier "preferred" characterset to utf-8 if they wish, but the language files themselves should be utf-8. 

XMLHttpRequest (used by _geturlcontent) is supposed to determine from the character-encoding heading set by the server on loading the language (file) that the data it's loading is utf-8 (provided the server says that it is) and make that a unicode javascript string (object) corectl.

Infact, MSXML apparently ignores the characterset returned by the server and instead ALWAYS decodes the text (in "responseText") as utf-8 (http://www.forum4designers.com/message197591.html) , so infact, using _geturlcontent() simply isn't going to work with any other charactersets anway (in IE).  The only way to stop that is to use either a BOM (Byte Order Mark) indicating it's a different UNICODE encoding (ie you can't use a BOM to indicate it's ISO-8859-1, that's not unicode), or to wrap it in XML which specifies the characterset and use responseXML to get at the data.

I think the answer is simple, have all language data mandatorally utf-8, if translators write in another characterset we can convert that before adding it to xinha (using iconv etc).  For IE it would probably work just fine (because it always assumes utf-8 unless a BOM is present indicating one of the other unicode encodings (utf-16 etc)), for Mozilla, I think the implementor just has to make sure that thier server sends correct character encoding of utf-8 for these files - unless we can find a way to force the Gecko XMLHTTPRequest to interpret them as utf-8 nomatter what the server calls them, which would be preferable.

Infact, this extends to all javascript files etc that is loaded as part of Xinha, all files should be utf-8 (although I expect most files apart from the language data wouldn't need to use any double byte characters anyway so it's a largely moot point).

OK, it is a feature of trac.. I've asked python-hosting if they can setup a ticket notification email to go to a mailing list I'll setup.  Just depends wether they (PH) will do so on the freetrac accounts, I'll post here when they get back to me.

From what kind of button?  In the toolbar, or just a normal form button?

For the toolbar...

      xinha_config.btnList["my-preview"] =
       [ function(editor) { preview(1); }, // action
         "Preview?", // tooltip
         "my_preview.gif", // image
         false // disabled in text mode
       ];
      xinha_config.toolbar.push(["my-preview"]);

For a normal form button...

<button onclick="preview(1)" value="Da Button" />

It'll be the relative position that throws things off I expect.

Quotes should always be used.

That's invalid HTML, the inner quotes must be entities.

To put it simply, in WYSIWYG mode, Xinha can only deal with perfectly valid HTML. That means that quotes will, and must, be entities except where they delimit an attribute value.

If you want to use invalid HTML such as the above you will have to "massage" it so that is IS valid html when you give it to Xinha, and "massage" the valid html that Xinha gives you back into your invalid-html markup.

Can you post your configuration please.

Afraid not.  Best way to learn is to look at the existing plugins, try the SuperClean plugin for example.

I havn't used the DynamicCSS or CSS plugins.  If you find a solution it would be good if you can post it so others can benefit.

The Stylist plugin uses extra space because it allows you to apply multiple classes to the selection, rather than the others which can only apply one class per selection.

1. I don't like the idea of on-demand plugin loading.  Plugins should be loaded once at runtime, BUT, the plugins themselves should be designed so that thier initialization can be done "in the background" or on demand.

2. Parsing XML is slow.  eval(javascriptCodeHere) is fast.  Whats the point of PHP -> XML -> Javascript instead of just PHP -> Javascript, there is no advantage gained by the XML adbstraction in this case.