incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <ole...@gmail.com>
Subject Re: svn commit: r1455576 - in /incubator/bloodhound/branches/bep_0003_multiproduct/bloodhound_multiproduct/multiproduct: api.py hooks.py web_ui.py
Date Wed, 13 Mar 2013 16:15:22 GMT
On 3/13/13, Branko Čibej <brane@wandisco.com> wrote:
> On 13.03.2013 09:31, Olemis Lang wrote:
>> On 3/13/13, Jure Zitnik <jure@digiverse.si> wrote:
>>> On 3/13/13 8:58 AM, Olemis Lang wrote:
>>>
>>>> -0 ... I'd suggest (?:(?!\d)\w+) ... which is already available in
>>>> multiproduct.util.IDENTIFIER after recent patches .
>>> Sure, we can go with that one too ...
>>>
>> things like Hønsdrükḱenshàpełlmünçen (i.e. unicode chars ;) will be
>> supported , which is nice to have ; and will be matched by TracLinks
>> expressions
>> ;)
>
> I very much disagree with using something like that as the tag that is
> effectively a unique key in database columns.

I don't think that would be more problematic than what we have right
now . Just notice that wiki page name (+ version) is a key field in
wiki table . I just created one such wiki page named ÁéíóúÄëïöü and it
goes through without any particular trouble . Indeed if you make the
experiment just type ÁéíóúÄëïöü inside in any other wiki text and
Trac's built-in wiki parser will even detect it as a CamelCase
expression . Isn't it great ? :)

Then I type
http://server.tld/bh/env/wiki/ÁéíóùÄëïöü and everything works as a charm ...

> Display name is different,
> but for database debugging, I really don't want to have to tell the
> difference between i and í and ì and ı.
>

I understand your point

OTOH we have a deployment with product prefix all in Simplified
Chinese (I will not have the courage to suggest a CamelCase expression
like I did above :P) and I see no particular reason for limiting users
this way , if they want to . Trac core is smart enough to deal with
these matters . Other deployment-specific concerns such as missing
keyboard layouts will not be a problem in many contexts .
Laissez-faire !
;)

Considering those facts I kindly request to make support for unicode
product prefixes an option , turned off by default .

-- 
Regards,

Olemis.

Mime
View raw message