Hi.
If we japanese make character mappings, it will be millions and can't
cover all of them.
Mapping plan doesn't seem realistic for Chinese too.
So I agree with Antonio and Bill.
But people who use latin charcter prefer mappings to encoding, I think.
How about plugable python logic with each c
Here're Serbian mappings (default Serbian language in Django is Serbian Latin):
var SERBIAN_LATIN_MAP =
{
"š": "s", "đ": "dj", "ž": "z",
"č": "c", "ć": "c"
}
var SERBIAN_CYRILLIC_MAP =
{
"а": "a", "б": "b", "в": "v",
"г": "g", "д": "d", "ђ": "dj",
"е": "e", "ж": "z", "з": "z",
"и":
2006/7/12, Bill de hÓra <[EMAIL PROTECTED]>:
>
> Malcolm Tredinnick wrote:
>
> > Personally, I was kind of hoping whoever wrote
> > the patch might think this sort of thing through and give us a concrete
> > target to throw ideas at. :-)
>
> Hi Malcolm,
>
> Here we go:
>
> [snip]
>
>
> I need to t
Andrey Golovizin wrote:
> Bill de hÓra wrote:
>> I need to test this properly and fill in the mappings
>
> The official Cyrillic-Latin mapping could be found here:
> http://en.wikipedia.org/wiki/Translit
Great resource Andrey, thanks. I'll fold that mapping in.
cheers
Bill
--~--~-~--~
James Bennett wrote:
> On 7/11/06, Bill de hÓra <[EMAIL PROTECTED]> wrote:
>> I need to test this properly and fill in the mappings, but the gist of
>> the approach should be clear. When that's done, unless someone has an
>> objection, I'll file a patch against
>
> The structure and logic look go
Malcolm Tredinnick wrote:
>> return s.substring(0, num_chars);// trim to first num_chars chars
>> return s.substring(0, num_chars);// trim to first num_chars chars
>> }
>> ]]]
>
> Probably only one of the last two lines is necessary. :-)
DRY!
> I am the about the worst guy in the worl
On 7/11/06, Bill de hÓra <[EMAIL PROTECTED]> wrote:
> I need to test this properly and fill in the mappings, but the gist of
> the approach should be clear. When that's done, unless someone has an
> objection, I'll file a patch against
The structure and logic look good; my only worry is that this
Bill de hÓra wrote:
> I need to test this properly and fill in the mappings
The official Cyrillic-Latin mapping could be found here:
http://en.wikipedia.org/wiki/Translit
It could be like this:
var RUSSIAN_MAP =
{
"а": "a","к": "k","х": "kh,
"б": "b","л": "l","ц": "ts",
"в": "v"
On Wed, 2006-07-12 at 02:54 +0100, Bill de hÓra wrote:
> Malcolm Tredinnick wrote:
>
> > Personally, I was kind of hoping whoever wrote
> > the patch might think this sort of thing through and give us a concrete
> > target to throw ideas at. :-)
>
> Hi Malcolm,
>
> Here we go:
aah ... batter u
Malcolm Tredinnick wrote:
> Personally, I was kind of hoping whoever wrote
> the patch might think this sort of thing through and give us a concrete
> target to throw ideas at. :-)
Hi Malcolm,
Here we go:
[[[urlify.js:
var LATIN_MAP =
{
'À':'A',
'Á':'A',
'à':
On 4/8/06, Petar Marić <[EMAIL PROTECTED]> wrote:
> 2. What about languages that have way too many symbols in them, ie
> Chinese, Japanese, Thai? AFAIK, in them one symbol represents a
> whole word.
> Should we include them also or leave them out? Or does someone out
> there have a better solution?
> @Arthur: You know what? Why don't we just do whatever feels more
> natural to our language? Then again, I can sense some transliteration
> collisions on the way.
Absolutely, this should be language specific. If you look at the
proposed list, you see that there are different transliteration
patt
> If we decide to go the sound-alike route, a good resource to start
> from might be the Textpattern CMS (which is in the process of
> transitioning to a BSD license, so we could eventually base something
> on their work once that happens), which includes a file used for
> transliterating URL slugs
> > I suggest we change urlify.js in a way that will not block out
> > non-English chars. Instead it should translate them into their English
> > feel-a-like, as suggested in #1602.
>
> If we decide to go the sound-alike route, a good resource to start
> from might be the Textpattern CMS [...]>
> h
On 4/8/06, Petar Mariæ <[EMAIL PROTECTED]> wrote:
> I suggest we change urlify.js in a way that will not block out
> non-English chars. Instead it should translate them into their English
> feel-a-like, as suggested in #1602.
If we decide to go the sound-alike route, a good resource to start
from
> Browsers now support Unicode URLs (albeit turned off by default in
> English editions lately due to security issues), might it make more
> sense just to allow non-English characters as is, if the said
> nationality might reasonably be willing/able to type them into the
> address bar?
That's true
Petar Marić wrote:
> I suggest we change urlify.js in a way that will not block out
> non-English chars. Instead it should translate them into their English
> feel-a-like, as suggested in #1602.
Browsers now support Unicode URLs (albeit turned off by default in
English editions lately due to sec
Greetings to all djangonauts out there,
I suggest we change urlify.js in a way that will not block out
non-English chars. Instead it should translate them into their English
feel-a-like, as suggested in #1602.
However we've got 2 problems:
1. Should we translate chars to their sound-a-likes or lo
18 matches
Mail list logo
