The stylized word is “شهداء”. So, the full sentence reads: “Martyrs on the way to Al-Quds (Jerusalem)”. Took a second to read 😅.

The second sentence which you transcribed correctly is “الشهيد المجاهد” i.e. “The Mujahid/Freedom Fighter Martyr”.

Hatsune Miku: Project DIVA series

If i had to guess, what they’re most likely refering to isn’t onomatopoeia, but it’s pronunciation. Vore in Japanese is 「丸呑み」(swallow whole) which is pronounced as まるのみ and sounds like 「丸のみ」(only circles) .

Using this as a rule for the date, the digits must be composed of only circles, i.e. either 0 or 8. This leaves only ８月８日 which fits the criteria.

FlorisBoard kinda died off for a year as patrickgold tried to implement statistical NLP suggestions. Thankfully, quite recently he opened up developments for contributors and people looking to help with the project on a long-term basis.

The alpha version of FlorisBoard has preliminary support for shape based Chinese layouts so you can write 汉字／漢字 with say, Cangjie or Zhengma. It also has the JIS kana layout for Japanese. Although, it doesn’t support Kanji Substitution yet, but you could use the shape based Chinese layouts for that in the meanwhile. As for Korean, it’s supported but no Hanja support yet.

While there isn’t a release for it yet, you can take any release artifact from the GitHub Actions CI and it should have it.

Except this isn’t really a problem in chinese. Sure there are many homophones but in general. Most 漢字 have one to two readings. Using your example, 人 is rén and 生 is shēng in 普通話. Meanwhile 重 can be read as zhòng or chóng. I’m not sure if this applies to the other languages in the sinitic family.

As for japanese the sheer number of kun readings is to Japanese overloading the few “simple” kanji to represent many words, it’s also not a real issue as almost always see okurigana to hint towards which specific reading you are using e.g. 生む vs 生える. Or the context informs which reading as in 生卵, i.e. the なま reading is only used as a prefix and so on.

The problem only kinda worsens with reading reforms as peoplr start the pack the simpler kanji with more readings when they’re used instead of the proper character. E.g. 函数→関数, both are read かんすう but the right is prefered because 函 is non 常用漢字

Native speakers and language learners alike build an intuition for the whole “Which reading should I use?” problem.

The tty isn’t practical for anyone using a language with non-latin characters. AFAik it doesn’t support unicode stuff like CJK languages or RTL/bidirectional text

There isn’t AFAIK. But In a nutshell it talks about OSS community dynamics citing the log4j exploit as an example. It seems like the same sentiment that western developers are echoing. Fostering respect and contributions from the consumers of their OSS and so on

This isn’t entirely true. The authenticator app option works with any OTP client. Infact, i’m storing my GitHub 2FA token inside of a KeePassXC database! You could also store it in something like password-store’s pass-otp and let the your client of choice handle it.