真的不知道这种歌词源是从哪里变出来的。
日文里掺着中文的简化字，但是还不是全都简化了，有些繁体字还是原有的样子，但是零星就看到几个简体字飘在里面。

我甚至有点怀疑这是不是哪个日文学的不好的人手写识别出来的歌词……（虽然中日双语种混合手写识别我只见过 Google 有，而且那个是啥语言都混合的）

🐦

<[ 📞 ﾂｳﾜﾊﾎｶﾉﾕｰｻﾞｰﾖﾘﾄﾘｹｻﾚﾏｼﾀ ]
[ ﾖﾋﾞﾀﾞｼﾊﾎｶﾉﾕｰｻﾞｰｶﾗｷｮﾋｻﾚﾏｼﾀ 📞 ]>
#i18n之所以难

https://t.me/JISFW/18332?single

顺便解说一下吧
这个明显就是软件国际化（i18n）过程中多方没有协调好造成的。

UI 方面
有时候 UI 上面有的字串无论怎么翻译，在某些语言里面都会变得很长。这时候 UI 就需要对这些情况作出考虑和妥协。能看出来这里面 WC 的做法是把字号改小来适应字串长度，所以是有做这方面的考虑的，至少比强行截断或者加省略号要好一些。不过更妥善的方式应该还是尝试折行，毕竟字太小有时候还是看不清。

翻译方面
IM 软件的通话功能已经不是什么新鲜事了。看着原文的「对方已取消」、「对方已拒绝」这简短的五个字，在这个随便省略点句子成分也无所谓的日语里面，应该能想到一些方法来缩短翻译串。同比 Telegram 的翻译指引里面就有「参照当地同类软件的用词习惯」这样的讲法。当地使用较频繁的 Line 对这两个状况的翻译分别是「不在着信」和「応答なし」，观感上就比那一长串要好得多。

#Protip
Use the built-in “Audio MIDI Setup” for a 0.1% precision volume control on your macOS.

🐦

debug 了半个多小时，结果发现问题出在 type-graphql 的逻辑考虑的不全，输入参数没能支持多维数组上。遂发 issue 与之。要是再花点时间搞明白它们的单元测试结构，应该能写个 PR 出来。

🐦

坐等今年的 T 恤衫。

🐦

一直以为 Android 的 CallScreeningService 能像 iOS 的 CallKit 一样给一个统一接口显示一行字在来电界面上，到现在才发现那只是丢给你个电话号码叫你自己去画 UI。

难怪那些来电识别工具看起来都那么不协调。

🐦

#Telegram小考察 《关于🎰》

「Telegram 赌场化不可避。」

这次的花样比较多。截至目前的状态：
- 仅 macOS beta 版本获得支持
- 发送方式与以往的赌场 emoji 一样。
- Bot API 暂时屏蔽了此类消息
- 中了三连 BAR、三连 🍇 好像也没有什么特效（还没抽中三连７）

虽然 Bot API 的返回数据看不到了，不过好在 macOS beta 的日志是有完整 MTProto 输入输出的，大概还是能从那边一探究竟。

【数据结构】
虽然与以往不同这次的🎰是三个值在变化，但是还是没有出现新的数据结构。沿用了以前的 emoji + int 的格式。只是这次的 int 应该是把这里面所有可能的组合全都编码进去了。

—

经过一番豪赌胡乱尝试，基本搞清了规律。
- 取值范围：1～64
- 单一卷轴有四种图案：BAR、🍇、🍋、７。
- 上面四种图案依次指代四进制的 0、1、2、3。
- 三个卷轴按照左低右高的形式构成一个三位数。
- 这个三位数转成十进制，然后加一就是这个组合的编号。

例如：
- BAR BAR BAR = 000₄ + 1 = 1
- 🍇 BAR 🍋 = 201₄ + 1 = 34
- 🍋 🍇 🍇 = 112₄ + 1 = 23
- ７ ７ ７ = 333₄ + 1 = 64

inspired from https://t.me/tgbeta/4215

#TIL Using the `Range` Web API, I can finally measure the width of a substring of a rendered text without any DOM modification. This could give some performance improvement on my karaoke layout component.

Tho I still don’t think it’ll work well on iPad.

https://developer.mozilla.org/en-US/docs/Web/API/Range

🐦