docs: use 「」 instead of “” throughout for Chinese text

docs/loong-or-loongarch.md

@@ -8,12 +8,12 @@ sidebar_position: 2
 
 在自然语言中：
 
-* 中文名：首选“龙架构”，可选“龙芯架构”
+* 中文名：首选「龙架构」，可选「龙芯架构」
 * In English: LoongArch (short of “Loong(son) Architecture”)
 
 需要提及位数时：
 
-* 中文：“32/64 位龙架构”
+* 中文：「32/64 位龙架构」
 * In English: “32/64-bit LoongArch” or “LoongArch32/64”
 
 对于软件中不直接对最终用户可见的标识符：
@@ -23,17 +23,17 @@ sidebar_position: 2
 * 如果优先考虑对齐 GNU target tuple / Debian multiarch tuple: `loongarch`
 * 否则：试一试 `loongarch` 好不好看、好不好听。不行再 `loong`
 
-以上都可按需添加“32”、“64”等字样，如果具体使用时有需要区分位数的话。
+以上都可按需添加 `32` `64` 等字样，如果具体使用时有需要区分位数的话。
 
 ## 关于自然语言中的使用
 
-最早并没有“龙架构”这个名字。LoongArch 最早被与中文名称相关联，是在 2021 年
-4 月 30 日《龙芯架构参考手册》首次发布时：直到此时 LoongArch 才与“龙芯架构”一词并列，
-但使用“龙芯架构”的场合仍然很少。
-不过从龙芯中科微信公众号 2022 年 4 月 13 日首次使用“龙架构”一词开始，至今（2023 年初）
-人们在中文语境下基本都将 LoongArch 称作“龙架构”了。
+最早并没有「龙架构」这个名字。LoongArch 最早被与中文名称相关联，是在 2021 年
+4 月 30 日《龙芯架构参考手册》首次发布时：直到此时 LoongArch 才与「龙芯架构」一词并列，
+但使用「龙芯架构」的场合仍然很少。
+不过从龙芯中科微信公众号 2022 年 4 月 13 日首次使用「龙架构」一词开始，至今（2023 年初）
+人们在中文语境下基本都将 LoongArch 称作「龙架构」了。
 
-龙芯中科将“LoongArch”、“龙芯架构”、“龙架构”三种写法在中国注册了商标，
+龙芯中科将「LoongArch」、「龙芯架构」、「龙架构」三种写法在中国注册了商标，
 使用时可加注意。
 
 ## 关于 `loong` 与 `loongarch` 两种叫法（长短名的争端）
@@ -42,7 +42,7 @@ sidebar_position: 2
 这个架构的名字都叫 `loongarch`、`LOONGARCH` 或这个名字再加上后缀 `64`。
 但 `loongarch64` 的全称与常见的其他架构如 `x86_64`、`aarch64`、`riscv64` 相比
 显得有些长了，加之在 `ARCH=loongarch` 等情况下会显得更加冗余
-（这与中文母语者的语感不太相同：“架构是龙架构”六个字，在本条目作者采访到的许多人看来并不显得特别冗余），
+（这与中文母语者的语感不太相同：「架构是龙架构」六个字，在本条目作者采访到的许多人看来并不显得特别冗余），
 因此一些社区选择在讨论之后采用较短的名字 `loong` 或 `loong64` 称呼龙架构。
 这与许多社区将 `aarch64` 叫作 `arm64` 有异曲同工之妙。
 
@@ -52,9 +52,9 @@ sidebar_position: 2
 人们在使用拉丁字母时一般会避免出现两个名字只有一处 `i/l/1`、`O/0` 不同
 从而容易混淆的情况，即便当代的编程字体已经充分考虑了这一点使这些字符看上去有区分度。
 （并非所有时候都有得编程字体用。）
-因此对于“架构名”这种可能会被以小写形式使用的场合，`LA64/la64` 就不合适了。
+因此对于「架构名」这种可能会被以小写形式使用的场合，`LA64/la64` 就不合适了。
 
-“先来后到”在此处并不牵扯歧视。
+「先来后到」在此处并不牵扯歧视。
 因为如果龙架构在先、安腾架构在后，大家也会以同样理由拒绝 `ia64` 这个名字，
 这条世界线的人们大概就会称呼安腾架构 `intel64` 或者 `itanium` 了。
 
@@ -64,7 +64,7 @@ sidebar_position: 2
 
 除 LoongArch 外，龙芯中科实际在更早之前还注册了 LArch 这一中国商标。
 （疑似仿照 `AArch`？）
-在 GNU 工具链“三大件”的移植中，相关团队也大量使用 `LARCH` 字样称呼龙架构。
+在 GNU 工具链「三大件」的移植中，相关团队也大量使用 `LARCH` 字样称呼龙架构。
 但该用法一直未见于其他场合甚至龙芯中科其他团队的工作中[^1]。
 
 鉴于 2022 年以来 `loongarch` 与 `loong` 的称呼已经被多数项目采用，目前已经没有机会复活
@@ -76,7 +76,7 @@ sidebar_position: 2
 但在它首次被开源前便被替换为 `GOARCH=loongarch64` 了。
 后来再根据上游建议与社区意见改为 `GOARCH=loong64` 都是后话了。
 
-不巧的是，这些公开讨论的部分内容被个别围观群众理解为了“‘社区’向龙芯中科找茬”。
+不巧的是，这些公开讨论的部分内容被个别围观群众理解为了「‘社区’向龙芯中科找茬」。
 这些人不认为 `loongarch` 冗长[^2]，并且客观上 GNU target triples 等处也已经使用了长名称
 （最初的 `config.guess` `config.sub` 龙架构适配是由龙芯员工提交，使用了长名称），
 因此 ta 们认为允许 `loong` 的写法反而是增加了记忆负担。
@@ -86,7 +86,7 @@ sidebar_position: 2
 会认为 `loongarch` 是唯一可行的名称。凭什么不是别人来习惯龙芯做法？
 
 尽管实际上在软件源码和开发者交流中使用商标与否都不会影响该架构的营销推广，
-但考虑到这些主客观因素，在开头的指导原则中，本文作者仍在“维持龙芯中科注册商标完整”
+但考虑到这些主客观因素，在开头的指导原则中，本文作者仍在「维持龙芯中科注册商标完整」
 与尊重各项目现有实践之间尝试做了平衡。
 
 ## 龙架构在一些社区项目中的名称
@@ -130,4 +130,4 @@ RPM 上游遂迅速合并了。
 |Rust|`loongarch64-unknown-linux-gnu`|
 
 该表格没有也不能穷尽所有软件项目。
-如果您有补充，您可在页面底部找到“编辑此页”的链接（指向上游仓库中本页的源文件）。
+如果您有补充，您可在页面底部找到「编辑此页」的链接（指向上游仓库中本页的源文件）。

docs/old-and-new-worlds.md

@@ -14,7 +14,7 @@ sidebar_position: 3
 
 * 如果您目前在龙架构电脑上使用 Loongnix、麒麟或者 UOS 这些系统，几个月或一两年之后，一定会有一次全系统升级。
     * 如果您不升级，那么本身外界如何变化也与您无关。
-    * 如果您升级，那么升级之后您应该也感受不到使用上的差别，这其实就是“移民新世界”了。
+    * 如果您升级，那么升级之后您应该也感受不到使用上的差别，这其实就是「移民新世界」了。
 * 如果您目前在龙架构电脑上使用 Arch、Gentoo 等等这些系统，那么您已经是新世界住民了，这一切也与您无关。
 
 会被坑到的情况目前来看只有：
@@ -25,8 +25,8 @@ sidebar_position: 3
   会来到这个页面，基本是已经被坑到了，那就往下读吧！
 :::
 
-截至目前（2024 年初），LoongArch 有两套不兼容的软件体系，习惯上大家把它们叫作“旧世界”和“新世界”。
-龙芯中科的材料中也有“ABI1.0”、“ABI2.0”的提法（目前所见的表述均未在 ABI 与数字之间加空格）。
+截至目前（2024 年初），LoongArch 有两套不兼容的软件体系，习惯上大家把它们叫作「旧世界」和「新世界」。
+龙芯中科的材料中也有「ABI1.0」、「ABI2.0」的提法（目前所见的表述均未在 ABI 与数字之间加空格）。
 
 **旧世界**是指最早在龙芯中科内部适配的、随着 LoongArch 公开一并发布的那个 LoongArch 软件生态。
 **新世界**是指龙芯中科与社区同仁一道，以典型开源社区协作模式打造的，完全开源的 LoongArch 软件生态。
@@ -40,11 +40,11 @@ sidebar_position: 3
 
 在讨论龙芯话题时，新旧世界的说法仅仅被用来区分两个不兼容的 LoongArch 生态。
 MIPS 型号的龙芯既不是新世界也不是旧世界。
-一般只会说“MIPS 时代的龙芯”（the MIPS-era Loongson）怎么怎么样。
+一般只会说「MIPS 时代的龙芯」（the MIPS-era Loongson）怎么怎么样。
 
-“旧世界”、“新世界”的名词形式英译即为“the old world”、“the new world”。
-作形容词时一般以连字符连接前后部分即“old-world”、“new-world”。
-如果在一段话中频繁使用，有时也会用“OW”、“NW”的缩写形式。
+「旧世界」、「新世界」的名词形式英译即为「the old world」、「the new world」。
+作形容词时一般以连字符连接前后部分即「old-world」、「new-world」。
+如果在一段话中频繁使用，有时也会用「OW」、「NW」的缩写形式。
 
 ## 我在哪个世界？
 
@@ -80,7 +80,7 @@ interpreter /lib64/ld-linux-loongarch-lp64d.so.1, for GNU/Linux 5.19.0
 
 以上的判断都适用于系统 libc 为 glibc 且动态链接的程序。如果程序是静态链接的，便没有 interpreter 信息；
 如果程序是 Go 语言的或者使用了 musl 作为 C 库，那么文件里就没有对应到 `for GNU/Linux` 这部分信息的标记。
-这种时候试着运行一下就可以了，“异世界”的程序几乎没有可能正常启动。
+这种时候试着运行一下就可以了，「异世界」的程序几乎没有可能正常启动。
 
 当然，如果你得到的输出类似下边几行之一：
 
@@ -93,22 +93,22 @@ someprogram: Bourne-Again shell script, ASCII text executable, with escape seque
 一般脚本语言的程序都无所谓新旧世界的，但它仍然有可能依赖一些二进制组件才能正常工作：
 因此最靠谱的方法还是试着跑一下！
 
-## 为啥叫“新旧世界”？
+## 为啥叫「新旧世界」？
 
-在汉语圈其他领域已有“新旧世界”的说法了，例如“旧/新世界猴”、“旧/新世界葡萄酒”：
-这里的“世界”其实就是“大陆”。
+在汉语圈其他领域已有「新旧世界」的说法了，例如「旧/新世界猴」、「旧/新世界葡萄酒」：
+这里的「世界」其实就是「大陆」。
 LoongArch 的新世界也比旧世界出现得晚，并且也存在做事方式上的不兼容，相互之间也有一定的沟通交流，
 因此这样的类比在一定程度上还比较贴切。
 
-在技术领域，“新旧世界”的说法也有先例。怀旧计算（retro-computing）群体对
+在技术领域，「新旧世界」的说法也有先例。怀旧计算（retro-computing）群体对
 Macintosh 电脑的不同型号就使用 Old World、New World 来区分。
-他们的“旧世界”是指系统硬件包含一块 ROM 芯片，其中搭载了 Macintosh Toolbox 这个老固件。
-“新世界”硬件则没有这块芯片。
+他们的「旧世界」是指系统硬件包含一块 ROM 芯片，其中搭载了 Macintosh Toolbox 这个老固件。
+「新世界」硬件则没有这块芯片。
 使用 Old/New World ROM 的 Macintosh 型号就被叫作 Old/New World Macs。
 
 另一方面，使用 Linux 源码发行版如 Gentoo 的用户群体，
-口语上也有“重做世界”（rebuild world）之类的表达。
-此处的“世界”是系统上所有包的统称，
+口语上也有「重做世界」（rebuild world）之类的表达。
+此处的「世界」是系统上所有包的统称，
 这层意义上 world 的含义类似 userland：统称在用户态运行的所有程序。
 对 Gentoo 用户而言，还恰好表示 `@world` 集合。
 而 LoongArch 的新旧世界区分，很大程度上正是由于内核态提供的系统调用界面有细微差别，
@@ -193,7 +193,7 @@ Macintosh 电脑的不同型号就使用 Old World、New World 来区分。
 
 ## 常见的坑
 
-### 执行一个程序，报“没有那个文件或目录”，咋回事？
+### 执行一个程序，报「没有那个文件或目录」，咋回事？
 
 如果您执行一个程序却被告知这个程序不存在，类似这样：
 
@@ -206,7 +206,7 @@ zsh: 没有那个文件或目录: ./foo
 ```
 
 如果这个文件确实存在，那么大概率是您在尝试执行异世界的程序。
-不存在的文件并非程序本身，而是所谓“ELF 解释器”，
+不存在的文件并非程序本身，而是所谓「ELF 解释器」，
 即上文教你判断一个程序是新世界还是旧世界那里提到的 ELF interpreter。
 请换对应您系统的程序版本，或要求软件提供者增加适配。
 
@@ -222,9 +222,9 @@ zsh: 没有那个文件或目录: ./foo
 此时 Go 会故意访问一个非法地址直接崩溃
 （因为此时从程序视角看，必然成功的系统调用居然失败，证明内核服务已经不再可靠，继续下去没有意义）。
 
-### 龙芯提供了很多镜像源（“龙芯源”），我能用吗？
+### 龙芯提供了很多镜像源（「龙芯源」），我能用吗？
 
-龙芯确实提供了很多“龙芯源”。**旧世界开发者必须使用（系统可能已默认加载了相应的配置修改），新世界开发者不可使用。**
+龙芯确实提供了很多「龙芯源」。**旧世界开发者必须使用（系统可能已默认加载了相应的配置修改），新世界开发者不可使用。**
 
 出于 SEO 以及行侠仗义（天下开发者是一家）的精神，此处破例提供相应的旧世界文档。
 

newsletter/2023-07-03-this-week-in-loongarch-7.md

@@ -124,9 +124,9 @@ LASX 的指令模拟支持，内含所有 LASX 指令的语义建模。
 
 详见：[活动日程](https://wiki.aosc.io/zh/community/aoscc/2023/)。
 
-#### “龙芯与你：你问我答”问题征集
+#### 「龙芯与你：你问我答」问题征集
 
-近年来，由 LoongArch 架构驱动的龙芯 5000 系列处理器展现出了相当可观的性能提升，亦在开源社区中收获了不少人气；与此同时，企业与社区的“新旧世界”交替与在上游的碰撞与交流也成为了最近几年 LoongArch 生态参与者们时刻关注的事情。本次 AOSCC 我们有幸邀请到了来自 LoongArch 社区的上游贡献者和龙芯中科的工程师们来一同介绍和解答各位的问题和疑惑。
+近年来，由 LoongArch 架构驱动的龙芯 5000 系列处理器展现出了相当可观的性能提升，亦在开源社区中收获了不少人气；与此同时，企业与社区的「新旧世界」交替与在上游的碰撞与交流也成为了最近几年 LoongArch 生态参与者们时刻关注的事情。本次 AOSCC 我们有幸邀请到了来自 LoongArch 社区的上游贡献者和龙芯中科的工程师们来一同介绍和解答各位的问题和疑惑。
 
 考虑到日程安排较为紧凑，我们决定提前收集社区提问，请[使用本问卷](https://forms.gle/QgdzPmcXqjwitmQm7)提交您希望得到解答的问题。
 

newsletter/2023-07-10-this-week-in-loongarch-8.md

@@ -77,9 +77,9 @@ xen0n 7 月 5 日在社区[征询了](https://discourse.llvm.org/t/how-to-best-i
 
 详见：活动日程 (https://wiki.aosc.io/zh/community/aoscc/2023/) 。
 
-#### “龙芯与你：你问我答”问题征集
+#### 「龙芯与你：你问我答」问题征集
 
-近年来，由 LoongArch 架构驱动的龙芯 5000 系列处理器展现出了相当可观的性能提升，亦在开源社区中收获了不少人气；与此同时，企业与社区的“新旧世界”交替与在上游的碰撞与交流也成为了最近几年 LoongArch 生态参与者们时刻关注的事情。本次 AOSCC 我们有幸邀请到了来自 LoongArch 社区的上游贡献者和龙芯中科的工程师们来一同介绍和解答各位的问题和疑惑。
+近年来，由 LoongArch 架构驱动的龙芯 5000 系列处理器展现出了相当可观的性能提升，亦在开源社区中收获了不少人气；与此同时，企业与社区的「新旧世界」交替与在上游的碰撞与交流也成为了最近几年 LoongArch 生态参与者们时刻关注的事情。本次 AOSCC 我们有幸邀请到了来自 LoongArch 社区的上游贡献者和龙芯中科的工程师们来一同介绍和解答各位的问题和疑惑。
 
 考虑到日程安排较为紧凑，我们决定提前收集社区提问，请[使用本问卷](https://forms.gle/QgdzPmcXqjwitmQm7)提交您希望得到解答的问题。
 

newsletter/2023-07-31-this-week-in-loongarch-11.md

@@ -56,7 +56,7 @@ OpenSSL 的龙架构 AES 汇编加速的正确性，该员工援引「最新修
 「对于 `vshuf.b` 的控制寄存器中的每个字节，其未定义的最高 3 位不应被使用，
 否则指令执行结果不确定。」xry111 据此指出：
 
-> 根据 LA464 的实现“猜”的向量指令行为未必可靠。
+> 根据 LA464 的实现「猜」的向量指令行为未必可靠。
 
 （编者注：很遗憾，这意味着根据 QEMU 实现反推的指令行为也未必 100% 匹配真实或未来硬件行为，
 因此不基于官方手册二次创作（这目前被禁止）的指令说明文档总不免要经受些后知后觉的修订。

newsletter/2024-02-12-this-week-in-loongarch-36.md

@@ -31,7 +31,7 @@ tags: [每周一龙]
 在这里，我希望着重感谢几位维护者的贡献：
 
 - [陈嘉杰][jiegec]：实现自动化框架，大大提高移植维护效率；整理和维护 Chromium
-  补丁集，为用户们提供了又一理想的浏览器选择；在最后冲刺中贡献突出，让龙年第一天完成“合龙”成为现实；
+  补丁集，为用户们提供了又一理想的浏览器选择；在最后冲刺中贡献突出，让龙年第一天完成「合龙」成为现实；
 - [刘子兴][liushuyu]：实现了 Firefox WebRTC 支持，让使用龙架构参加在线视频会议和使用
   Discord 等语音聊天软件成为可能；提交了 GCC D 编译器和 LDC 的龙架构支持；
 - [王江津][RedL0tus]：为当前 AOSC OS 锁定的 GCC 13 和 Glibc 2.37 维护了矢量补丁；修复了