[pmwiki-users] Re: About the feature "Endings become part of, the link text."
songjl at 163.net
Mon Sep 19 20:43:40 CDT 2005
Now I understand your choice. I realize the XL-Page-UTF-8 solution is a
more convenient one than use option in .XLPage file. I agree with you.
Thanks for your patient introduction.
Patrick R. Michaud wrote:
> On Tue, Sep 20, 2005 at 12:31:54AM +0800, Elias Soong wrote:
>>I have test this on the Chinese main page of pmwiki.org. Gladly it is
>>what I need. However, I don't know if there are any non-european
>>language need "Ending become part of the link text", so this may not be
>>a safe bet.
> As we identify such languages, it's not at all hard to add them to the
> set of "allowed suffix characters".
>>Furthermore, there may be some English site want use UTF-8
>>encoding to be compatible with more languages.
> Yes, which is why I chose the particular solution I did -- for sites
> that are using european languages in a utf-8 character set (including
> English), they end up with the suffixes being part of the link text
> in exactly the right places.
>>Now, I suggest another choice. We could allow .XLPage file control this
>>option, then wiki administrators could choose for their own need. For
>>example, we could turn off "Ending become part of the link text" by
>>default for PmWikiZhCn.XLPage file.
> I thought of using an XLPage option, but this would go against
> exactly the situation described above. Suppose I have a site where
> my primary language is English, but I want to use utf-8 encoding
> for pages because some of the pages will contain a mix of english
> and asian text. (Yes, there are such sites.)
> An on-or-off option doesn't help here; if the site administrator
> uses XLPage to turn off suffixes, then they can't be used for the
> English links; if the site administrator uses XLPage to turn suffixes
> on, then the asian language portions of the page suffer because
> they're treated as suffixes.
> So, the better solution seems to be that only european characters
> are considered for suffixes (we can increase/modify this as the need
> is identified). This also has the advantage of not requiring an
> additional and potentially confusing "suffix" option in the XLPage
> file that will require documentation and explanation for people
> creating those files.
> Lastly, for any site that really needs something odd in turning
> suffixes on or off, the administrator can set the value of
> $SuffixPattern explicitly. :-)
>>>On Mon, Sep 19, 2005 at 05:56:57PM +0800, Elias Soong wrote:
>>>>Surely, "Endings become part of the link text." is a good feature for
>>>>English, but most asian language not use spaces. I suggest put this
>>>>feature to be an option of i18n settings and default to be actived. Then
>>>>we could set Chinese XL-Page disable this feature.
>>>As a slightly different approach, I think I've been able to modify
>>>the suffix pattern so that it only accepts "european" characters
>>>in the suffix. (These are code points U+0020 to U+058f for those
>>>who follow such things.) Non-european characters, such as those
>>>that come from asian languages, are not included in any link suffix.
>>>Does this sound like a good approach to you, and could you test
>>>this on pmwiki.org (in one of the utf-8 groups) and let me know
>>>if it seems to be working the way you would want for Chinese?
>>pmwiki-users mailing list
>>pmwiki-users at pmichaud.com
More information about the pmwiki-users