On 3/13/13, Branko Čibej <[email protected]> wrote: > [...] > No. I'm not worried about Unicode *validation*, I'm worried about > Unicode *normalization*. >
Before I was obviously misunderstanding what you were saying . >>> Database collations typically >>> are not normalization-agnostic. >>> >> Yes u'r right ... Trac core takes care of that . > > Where? > ... hence this is not accurate as I did not notice I was talking of another thing . [...] > > Only the second hit actually normalizes anything. Browsers, Javascript, > etc. etc. do not care about normalization, so two people, e.g., one > using Mac and another using Windows, can create a product with the tag > > unglücklich > > and would get two different products with what appears to be the same > prefix -- but with one in NFD form and the other in NFC form. > I'm hoping we can reproduce such scenario(s) in a test case ... based on your experience do you think having two different OS will be the only way to reproduce this situation ? > If you insist this is up to trac-core, No . Like I said in my previous message the initial proposal does not touch anything in Trac core . It's about product prefix , so like I already said BH is the target . > then this needs to be fixed > there; however, I'd expect such a fix to also require a database upgrade > -- i.e., explicitly normalizing all such keys in existing databases. > +1 > Of course that could lead to conflicts, but its better to resolve them > by renaming the keys than by not doing the homework WRT Unicode > normalization in the first place. > We shall see . https://issues.apache.org/bloodhound/ticket/463 > > FWIW, Subversion suffers from the same problem, and it's even harder to > fix there, which is why I'm kind of sensitive to it. > ... and you are right . Good you were around , otherwise that would have been overlooked . -- Regards, Olemis.
