On Thu, 2009-05-07 at 21:54 +0200, Branko Vukelic wrote: > On Thu, May 7, 2009 at 9:49 PM, Janos Guljas <ja...@janos.in.rs> wrote: > > Hi, > > > > Here is a patch for urilfy.js in admin application that should support > > Serbian alphabet. There are no collisions between existing and new > > mappings. > > > > Is this OK with other language teams? > > We have mentioned this among ourselves in the Serbian translatiors > group, but since Janos hasn't mentioned it here, perhaps I could. > > The reason Janos mentioned 'collision' between existing and new tables > is that Serbian transliteration pairs collide with the Russian pairs > (a small subset, if I'm not mistaken). Serbian transliteration is not > by sound as Russian is, so > > in ru: ш --> sh > in sr: ш --> s > > This is a minor problem that most people will overlook, and there > doesn't seem to be a reasonable solution to it. If someone thinks of > something that could solve this issue, please let us know.
Good to mention it, because that's the question I would normally ask in this type of situation (although Janos explicitly ruled it out). Fact of life is that there isn't going to be a perfect way to do that and we shouldn't worry about that at all. The "slugify" process is imperfect. It's also an approximation and there is no correct answer in any language at all, since it intentionally throws away information. If people want to use it, they are free to do so. If it isn't what they are after, then the solution is not to use it. For the record, the issue gets much more complicated when you consider East Asian languages (Chinese, Japanese, Korean, etc). Our goal is reasonable efforts and acknowledging that this is, by definition, an approximate solution. So I think this is fine. Having the full explanation on record is useful, too. You know that at some point in the future somebody is going to open a ticket saying that Serbian transliteration handles ш incorrectly and, even when we point out why, will argue that it should be the Russians who suffer. I think your current approach is as good as we can do with that particular function (locale-specific functions are a more specialised possibility, but they shouldn't be in core, at least not until they've been proven externally first). Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django I18N" group. To post to this group, send email to Django-I18N@googlegroups.com To unsubscribe from this group, send email to django-i18n+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Django-I18N?hl=en -~----------~----~----~----~------~----~------~--~---
