Hello

I am interested how to change the charset of the whole site. I have not managed to find where it could change. Current UTF-8 does not show properly Croatian characters.

Sorry for bad english: D

Could you please share a link to a site where the problem with Croatian and UTF-8 occurs? UTF-8 should work fine with accents of every variety. Does this happen everywhere across the site, or only in the comment and other popup boxes?

In any case, the page's header HTML code is under templates/default/skin_global.php. Find the following (line #105):

<meta content="text/html; charset=utf-8" http-equiv="Content-Type" />

And change that to the character set of your choice. There are also some charset-specific MySQL database settings, but let's get there only if this doesn't help you out.

problem occurred only in boxes and some parts that I translated. For now, I have resolved so I threw out the characters who have not worked.

Is it possible to write some sort of function that will convert characters čćžđš in cczds when users attempt to use these characters in posts, articles ...

In addition, interested if possible to throw some of the fields when adding articles and groups? I'd like to throw out the fields city, country and perhaps even some. Thank for your reply, and once again sorry for bad english

For a fix on the boxes, please see this. Which translated parts are affected?

Yes, I can of course code a function to filter characters to their ASCII equivalents, but I'd rather see them working properly, because they should. =)

To edit the fields that are shown, you can edit the templates /templates/default/skin_posts.php etc., or skin_forms.php for the forms.

Dear Markus,

Hi,

Thanks for your good script.the problem for the utf-8 charset still exists in the latest release too.please help me how I can use iwiccle with farsi characters.all inputs in ajax forms will be damaged after submition.

Thank you

Hi Rezashah, and thanks for reporting! I havent checked the system with Farsi yet, a full multilanguage sweep is on my near future tasklist. (Hopefully addressing all multilanguage problems across scripts.)

The problem with AJAX happens because the Unicode post data gets encoded while it passes through javascript, and then fails. Just haven't had time to crack this one yet, it shouldn't be too complicated to sort out.

Bug report tagged.

I will follow with my technical team to find out if we can fix it or not. please let me know where should we start from as we are new to iwiccle.which files and functions we have to trace?

thanks

I have now fixed the AJAX issue and done a bit more in the way of multilanguage testing (not that hard once you know the lay of the land). The issue here was simply one of overlapping html entity handling, which threw the unicode HTML characters off.

Please have a look at a beta development build where this is now fixed. I don't read Farsi (not yet anyway), so I'm left with a visual comparsion to check for text integrity — there shouldn't be anything odd changing when the script displays right though.

Please test all areas of the system in Farsi as far as you can (along with your tech team), and link here URLs to pages where you spot a problem, along with a note on what the problem is. For issues that that are quick enough to fix — no need bugging your tech team with them, since we need these fixed for our software as a priority anyway.

I am still improving some areas, and have noticed a few more quirks in multilanguage behavior, such as:

• Automatically generated browser title bar text for posts gets corrupted on the way
• Verbose post identifiers (that you see in the URL) aren't generated properly for Farsi only post titles, as there are no characters in the recognized range for identifiers. (Any thoughts on how to generate unique and useful page identifiers? Or, what would make SEO sense to use as a Farsi page URL?)

These fixes, along with a good deal more, will be rolling out as soon as I get a moment to check through and wrap up the build for release.

Its not only an AJAX issue, it can also occur because the wrong charset type is set in the HTML document. I have had the problem occur for characters generated outside of the texteditor also.

For instance, the fádá is an important grammatical element of the Irish language - see our national broadcaster RTÉ for example. I was trying to use a script to import news feeds from the business section of their site but the É in the RTÉ was getting jumbled up.

rezashah, try the following:

• Open up skin_wrappers.php.
• Go to line 72
• change:

<meta content="text/html; charset=utf-8" http-equiv="Content-Type" />**

to

<meta content="text/html; charset="iso-8859-1" http-equiv="Content-Type" />

** (Markus, note missing leading double quote on charset)

ISO 8859-1 encodes what it refers to as "Latin alphabet no. 1," consisting of 191 characters from the Latin script. This character-encoding scheme is used throughout The Americas, Western Europe, Oceania, and much of Africa. It is also commonly used in most standard romanizations of East-Asian languages.

Each character is encoded as a single eight-bit code value. These code values can be used in almost any data interchange system to communicate in the following European languages (with a few exceptions due to missing characters, as noted):

Modern languages with complete coverage of their alphabet

Source

Kyle; have you looked into how non-UTF charsets work across the system? UTF should support all character ranges, need to dig further into what causes some of the extended Latin characters to not work. (I bumped into the same problem with some Scandinavian characters.)

In the meta tag, there are only two parameters, namely content and http-equiv. There is no separate charset parameter in this context. As such, "text/html; charset=utf-8" is part of a single parameter, and doesn't take the extra quote. (More on that.)

I haven't, Markus, no. That was merely a quick fix but it seemed to do the trick fine!

Re: the quotes, whoops, my bad. I missed the semi-colon. Powerful and all as they are, and bearing in mind the great use you've made of them for parsing things to-and-fro, one of my gripes with the use of the << WIC heredocs is that they prevent colour highlighting of text in editors. Have you come across any editors or plugins that will still highlight tags inside these?

Some new experiments with Chinese and Portuguese in the current Beta build. If you understand a language using a complex script or other non-ASCII characters, please consider testing and reporting as necessary.

On a related note, I wanted to use the multi-language versions of the UN human rights charter as sample text across all languages, but their entire multilanguage site has been down for over a week... Someone's asleep at the wheel big time there!

--

Kyle, do you mean highlighting HTML syntax? In Notepad++ (which I believe we both use), HTML inside a PHP block doesn't get highlighted, whether you use heredoc or regular quotes around strings.

If you need to see the HTML highlighted in a template file, a quick and ugly trick is to just temporarily remove the

Hi, Markus!
I've been away for a long time due to personal problems but now I'm back for good. I'd like to tell you my impressions about current version of iWiccle, but I'll leave that for another post
As to the current discussion, the problem with special characters in Portuguese seems to be partially solved in Beta build.There is nothing wrong with the text that I publish, including titles, captions and all text displayed within the page itself.
However, there is still some problems with chars at browser's caption and address bars. Perhaps it would be interesting to think about a new way to create these strings? Something more like "permalinks" in Wordpress? Is it possible?
Anyway, it's great to be back

Hi Iggy,

Welcome back! I will look at fixing these two, the title bar and the nav stream, for the upcoming update release. I believe there will still be some undiscovered multilanguage quirks there, but at least that'll get the basics sorted out and solid.

As far as the content identifier strings used in the URLs, there is a configuration switch that will generate them based on content type and database ID instead of the original title:

$core['module']['posts_no_ident'] = TRUE;

Setting this to TRUE will name the posts as "post_1979" etc. instead of a verbose identifier "my_post_title". It is in use for example in the forums module (also here -- see when you click "Post #13" at the top left of your post above).

There is also an option that will generate a longer unique identifier if the resulting string length is less than X characters long (currently 1 — configurable in the next release), as follows:

$_SESSION['module']['module_ident']."_".$_SESSION['member']['member_ident']."_".date($core['init']['date_short'])

Which translated into a human-readable example would mean for example: articles_iggy_2010-06-25 (or _1, _2 etc. appended for multiple entries per date).

These identifiers could really be generated in any whichsoever way you wish (in class_elements.php / make_ident function), as long as they are all unique and permanent links to these specific entries. As such, they are for all practical purposes "permalinks", with the exception that multiple edits to content don't (yet) result in history versions and new permalinks.

Hey, this is great news! It was exactly what I was thinking when I spoke of "permalinks". You're the best!

For reference, these options are available in variables.php for the next WWB and iWiccle builds:

$core['module']['ident_min_length'] = 4; // Minimum length for entry identifier string (used for example in the URL)

$core['module']['ident_max_length'] = 40; // Maximum length for entry ident string

$core['module']['ident_type'] = "verbose"; // Options: verbose = "what_i_just_wrote" -> taken from entry name / namedate = "blogs_joe_2010-06-30" etc. / database = "post_1345"

$core['module']['namedate_ident_format'] = "[[MODULE]]_[[NAME]]_[[DATE]]"; // Tags are replaced with module ident, user ident, and date

$core['module']['namedate_ident_date_format'] = "Y-m-d_H-i"; // See PHP date() function for date and time syntax reference

$core['module']['allow_pure_numeric_ident'] = TRUE; // False appends first character of table name (e.g. "w_posts" -> "p") to pure numeric identifiers (e.g. "p_15123")

If someone wants to customize their identifiers further and for example add more tags to namedate_ident_format, all of this happens under make_ident() in class_elements.php (second function in the file).