Live data from Hacker News

Charset="WTF-8"

wtf-8.xn--stpie-k0a81a.com

401–410 of 463 posts

Re: Charset="WTF-8"

#401

Earlier quoted context omitted.

Fonts are already in there and proto-glyphs are too as generalized dicritics. There's also a large variety of generic shapes, lines, arrows, circles and boxes in both filled and unfilled varieties. Lines even have different weights. The absurdity of a custom alphabet can already be partially actualized. Formalism is merely the final step This conversation was had 20 years ago and your (and my) position lost. Might as…

The diacritics are there because they were in legacy encodings, and it was decided at some point that encodings should be round-trippable between legacy encodings and unicode. The fact that hardly anyone cares any longer are about going to any legacy non-unicode encoding is, of course, a testament to the success of unicode, a success that required not only technical excellence but figuring out what would actually wor…

It's the other way around - precombined characters (with diacritics) are there because they were in legacy encodings. But, assuming that by "generalized diacritics" OP means Unicode combining characters like U+0301, there's nothing legacy about them; on the contrary, the intent is to prefer them over precombined variants, which is why new precombined glyphs aren't added.

Re: Charset="WTF-8"

#402

Well, the labels of input fields are written in English yet user enters his name in native language. What's the reason of having name at all? You can call the person by this name. But if I write you my name in my language, what you (not knowing how to read it) can do? Only "hey, still-don't-know-you, here is your info". In my foreign passport I have name __transliterated__ to Latin alphabet. Shouldn't this be the cas…

Unfortunately, the extremely weird and idiosyncratic use of Latin script for English means that straightforward transliterations are usually pronounced incorrectly by people who try to pronounce them according to English rules.

And, on the other end of the spectrum, you have attempts to spell phonetically following English orthography, which then causes issues because it's tied to a particular dialect of English. E.g. the traditional Korean romanization of the name "Park" has "r" there solely so that "a" would actually correspond to an [a] sound in British English - but then, of course, American English is rhotic, and so it ends up being incorrectly pronounced as [park].

Re: Charset="WTF-8"

#403
post #131

Earlier quoted context omitted.

You miss "ę"!

I don't think I did. I watched the video and this is the phonetic transcription. I hear b zh e n ch ...

"ę" is not [e] followed by [n], it's a single nasalized vowel.

Kinda like "ň" in Czech is not just [n] followed by [j], although it kinda sounds like that to people whose native language does not have a palatalized N sound.

Re: Charset="WTF-8"

#404
post #97

Earlier quoted context omitted.

Honestly I wish we could just abolish first and last name fields and replace them with a single free text name field since there's so many edge cases where first and last is an oversimplification that leads to errors. Unfortunately we have to interact with external systems that themselves insist on first and last name fields, and pushing it to the user to decide which is part of what name is wrong less often than str…

It’s not just external systems. In many (most?) places, when sorting by name, you use the family names first, then the given names. So you can’t correctly sort by name unless you split the fields. Having a single field, in this case, is “an oversimplification that leads to errors”.

Right, but then you have to know which name is the family name, which really could be any of them.

Re: Charset="WTF-8"

#405

Earlier quoted context omitted.

The diacritics are there because they were in legacy encodings, and it was decided at some point that encodings should be round-trippable between legacy encodings and unicode. The fact that hardly anyone cares any longer are about going to any legacy non-unicode encoding is, of course, a testament to the success of unicode, a success that required not only technical excellence but figuring out what would actually wor…

It's the other way around - precombined characters (with diacritics) are there because they were in legacy encodings. But, assuming that by "generalized diacritics" OP means Unicode combining characters like U+0301, there's nothing legacy about them; on the contrary, the intent is to prefer them over precombined variants, which is why new precombined glyphs aren't added.

Ah, right, thanks!

Re: Charset="WTF-8"

#406
post #12
post #8

Earlier quoted context omitted.

You may not want Bobby Tables in your system.

If you're prohibiting valid letters to protect your database because you didn't parametrize your queries, you're solving the problem from the wrong end

There might be more than just 2 ends. And some of them may not be fixable by you.

Re: Charset="WTF-8"

#407
post #317

Earlier quoted context omitted.

Unicode does not specify any fonts, though many fonts are defined to be consistent with the Unicode standard, nevertheless they are emphatically not part of Unicode. How symbols including diacritics are drawn and displayed is not a concern for Unicode, different fonts can interpret 'filled circle' or the weight of a glyph as they like, just as with emoji. By convention they generally adopt common representations but…

You can say things like the different "styles" that exploit Unicode on a myriad of websites such as https://qaz.wtf/u/convert.cgi?text=Hello are not technically "fonts" but it's a distinction without a meaningful difference. You have script, fraktur, bold, monospace, italic...

Fraktur is interesting because it’s more a writing style, verging in a character set in its own right. However Unicode doesn’t directly support all of its ligatures and such.

None of this is in any way justification for turning Unicode into something like SVG. Even the pseudo-drawing capabilities it does have are largely for legacy reasons.

Re: Charset="WTF-8"

#408
post #353

Earlier quoted context omitted.

I did this in the product where I work. We operate globally so having separate first and last name fields was making less sense. So I merged them into a singular full name field. The first and only people to complain about that change were our product marketing team, because now they couldn’t “personalize” emails like `Hi ,`. I had the hardest time convincing them that while the concept of first and last names are co…

I tried this too, and a customer angrily asked why they can't sort their report alphabetically by last name. Sigh.

Just split the full name on the space char and take the last value as the last name. Oh wait, some people have multiple last names.

Split on the space and take everything after the first space as the last name. Oh wait, some people have multiple first names.

Merging names is a one-way door, you can't break them apart programmatically. Knowing this, I put a lot of thought into whether it was worth it to merge them.

Re: Charset="WTF-8"

#409

Earlier quoted context omitted.

Quite the opposite actually. I want it stored correctly and in a way that both me and CSR can understand and so it can be used to interface with other systems. I don’t however know which unicode subset to use, because you didn’t tell me in the signup form. I have many options, all of them correct, but I don’t know whether your CSR can read Ukrainian Cyrillic and whether you can tell what vocative case is and not use…

I think you're touching on another problem, which is that we as users rarely know why the form wants a name. Is it to be used in emails, or for sending packages, or for talking to me? My language also has a separate vocative case, but I live in a country that has no concept of it and just vestiges of a case system. I enter my name in the nominative, which then of course looks weird if I get emails/letters from them l…

> - Name for package deliveries. If I'm ordering a package from abroad, I want my name (and address) written in my local convention - I don't care if the vendor can't read it, first the package will make its way to my country using the country and postal code identifiers, and then it should have info that makes sense to the local logistics companies, not to the seller's IT system.

I am not sure that what you ask is possible, there might be local or international regulations that force them to write all the addresses in a certain way.

But on the positive side, I have found that nowadays most online shops provide a free-from field for additional delivery instructions. I live in Japan, and whenever I order something from abroad I write my address in Japanese, and most sellers are nice enough to print it and put it on the side of the box, to make the life of the delivery guys easier.

Re: Charset="WTF-8"

#410

Earlier quoted context omitted.

It’s not just external systems. In many (most?) places, when sorting by name, you use the family names first, then the given names. So you can’t correctly sort by name unless you split the fields. Having a single field, in this case, is “an oversimplification that leads to errors”.

Right, but then you have to know which name is the family name, which really could be any of them.

I’m not sure what you’re trying to get at. The field containing the family name is the one labelled “family name”. You don’t have two fields both labelled “name”; there’s no ambiguity.
Post reply on HN