Non-ASCII pony names

[maandree]

Mjölna and Jesús Pezuña (the ones I know of so far) have non-ASCII letters
in their names. What should we do in this cases, I see that we have three options:

option 0: ASCII:ise the names
option 1: Use UCS in names [that is, as spelled at the beginning of this issue]
option 2: ASCII:ise the names and create symlinks with UCS in names

I am for option 1.

[etu]

I like option 1.

Ponysay uses plenty of UTF-8 already. So why not some more?

[maandree]

One reason is that it may cause problems using UCS on exotic systems, such as Windows.
Well I only known that Windows have problems [or at least hade some years ago], every GNU distribution should support it or die trying.

[maandree]

Vinyl Scratch is spelled Vın̈yl Scratch according to http://mlp.wikia.com/wiki/Vinyl_Scratch

This may be displayed badly depending on and browser, it is:

v [Victor]
ı [India, dotless]
n̈ [November, diaeresis] This a composed character (combining diacriticals + letter)
y [Yankee]
l [Lima]

Should spell it vinyl or as above if we decide to use UCS?
The ı is simple to create in X [alt graph + shift + i],
vı will suffice for completion so the n̈ will not be a problem,
but in TTY where are problems: Standard keyboard layouts
does not contains ı and both ı and the combining ¨ are not displayable
and therefore replaced with � [U+FFFD].
A suggest using the ASCII spelling for this case.

[JotaRandom]

another example is 'Piña Colada' (actually in my branch)
I pushed using pinacolada, not all keyboards and not all peoples know the asci code for ñ/Ñ (actualy I know only 3 linguages using Ñ for example), same aly for " alognside an N

I prefered pinacolada or VinilScratch, for those poor that not know how on equestria make these chars

[maandree]

Many keyboard in X support ñ using compose (not usually enabled by default though),
this is also true in Linux VT, where compose key is placed on SysReq by default.

I think all keyboard layouts, in X, that have latin characters support ñ.

Swedish, Finnish and International English supports ñ through deadkeys.
Spanish and International English have direct key for ñ.
Spanish, and all English supports ñ through compose.

Xterm with default supports ñ through alt.

[maandree]

Assuming use of Compose (when needed) all keyboard layout with the latin letters
support all UCS names in both Linux VT and X, except for Vın̈yl Scratch spelled in http://mlp.wikia.com/wiki/Vinyl_Scratch

Many latin based keyboard layouts support ñ with direct key or dead key (less through dead keys.)

Compose should be considered a requirement for many keyboard layout, since some letter in English can only
be written with it; English uses the following characters [many of which are supported through dead keys),
of cause, many people ignore it, probably because of the lack of the in early computing:

à
á
é (common, e.g. résumé)
ç (common, e.g. façade)
ó
è
å (somewhat common, e.g. ångström)
ê
î
ö (somewhat common, e.g. ångström)
û
ñ
â
ë (common, but often ignored)
ü (common, e.g. über)
ấ (rare)
ï (common, e.g. naïve)
č (rare)
ỏ (rare)
ā (rare)
ø (rare)
ở (rare)
ù
ä (common, e.g. common dopplegänger)
æ (very common, except for in American English, e.g. formulæ, encyclopædia)
œ (rare)

[JotaRandom]

ü (common in spanish, like: agüero)
œ (old french if my memory is correct)
ở (common in Vietnam language and pinyin)

but chage the letter not make more dificult to read or display if used font w no support for these leters?

[maandree]

So ASCII for those with legacy keyboard layouts and without compose don't have any problem.

Apart from vinyl (which have the symlink djpon-3) piñacolada would be the the only that can't be
written with only ascii and completion [at "pi" there are for example also "pinkie"].

Mjölna and Jesús are autocompletable before the non-ASCII.

[etu]

I think windows is a non-argument. All real OS can handle UTF-8 chars. But I agree with the points about that some chars might be hard to type for some people. I would say, create the ponies with USC-names, and symlink ASCII-names?

One more thing that I have been thinking about is the cases of the names, why all lowercase? We could use cases to show this is a new part of this ponys name. Like Vın̈yl Scratch gets the filename... Vın̈ylScratch.pony

It would be possible to handle -f "Vın̈yl Scratch" and get the right pony.

And maybe add an argument, like this... -f "Pinkie Pie" -e "Cannon" or something? Sure the tabcompletion and the listing needs some work, but not that much. The only thing that needs some real thinking is the pony's filename-structure.

Therefore I propose this:

PinkiePie_Cannon.pony
Vın̈ylScratch.pony

Ponys with extras got the extra after the _, easy to parse, easy to write. And I could implement this today, I will be on a train all day anyways.

[maandree]

Camelcase names with _ for extra, and lowercase without _.
I'm for it.

Now that I also know that there are not that many ponies with diacriticals I'm also for both UCS and ASCII,
however I suggest ASCII with UCS symlinks because ASCII is guaranteed to always work.

[etu]

Updated my Repo, I will work on this today. I commit it later, say about ~15 CEST or something.

[maandree]

I'll be ready to pull then.

[erkin]

I'll be ready to tag v1.1 then.

[maandree]

I think as is now suffices for 1.1.

This feel like something that could take time to get working correctly with all parts
of the system and make sure it is stable. I suggest this waits to 1.2.

[maandree]

Oh, and I'll probably (not sure yet if it is a good idea) move ponyquotes4ponysay into this,
and also have kmsponies4ponysay ready, by a day or two.

[erkin]

Okie dokie lokie!

[etu]

Hmm, -e creates some interesting problems when combining with multiple -f's.

like... ponysay -f Fluttershy -f Pinkie -e Cannon "hello"

There's two ways to solve that: (what I can think of)

1. Let -e decide, fluttershy has no cannon, we must chose pinkie
2. Let -f decide anyways, and pick a cannon if there's one

And, support for multiple -e? Maybe? If yes, that can be done later.

I like option number 2, it makes the most sense to me.

[maandree]

I don't understand the options, but I would like:

ponysay [-f PONY [-e EXTRA_FOR_PREV_PONY]...]...

[JotaRandom]

not sure why but mjolna remain either the package in arch, the clone, the pull remin using utf-8 and no the Mjölna
but the commit is there the change is listed and showed, apparently or github or git or the filesystem (or my locale) dislike UCS chars...

[maandree]

We have not commited any UCS named ponies, so it should be mjolna, if you haved changed it to mjölna yourself.

[JotaRandom]

not i only make a
git pull
and a
mjolna.pony -> mj\303\266lna.pony
are showed in changes but the name remain intact
I supposed "my filesystem..." But now the 1.1 show same mjolna name
...is strange...

PD: I only change thinks previous question (like this one)

[maandree]

You must manually remove mjolna.pony from /usr/share/ponysay/*/, and then make install, that is where
the program looks for the ponies, even if you are in the directory created by git clone ...

[JotaRandom]

'git clone' clone a mjolna non-dieresis (or what-is-the name for ö)
but I se none decicion is taken alredy
you say: We have not commited any UCS named ponies
This make maybe an git error, but no-decicion is taken for this righth?

[maandree]

We have not made any decision.

[JotaRandom]

at the best case...simlink is enough..but is so many simlinking at the moment
for example: vinÿl ... vin"yl ... but I do not know how make vinyl correctly written .. pobably i'm not the only, the _ for spaces is a good idea, but " ....

[maandree]

I will implement this as an optional feature using environment variables.

PONYSAY_UCS_ME for creating UCS names as alternatives, simulating symlinks.

PONYSAY_UCS_ME can be yes, y or 1 to enable this or
harder, h or 2 for simulating renaming rather than simulating linking.

[maandree]

UCS names are now supported, their UCS names are mapped in share/ucsmap.

Edit for previous spec:s for PONYSAY_UCS_ME:
PONYSAY_UCS_ME=harder will allow ASCII name in -f and -q but not list them in listing methods.