Xuan Wu

@RimoChan btw 缩进2格的问题是因为之前在vscode选项里加了全局的`"editor.tabSize": 2,`. [改](https://stackoverflow.com/questions/42118651/how-to-set-python-language-specific-tab-spacing-in-visual-studio-code)了之后就好了.

考虑也添加些常用算法，尤其是[排序相关的](https://www.crondose.com/2016/07/sorting-algorithms-important/)。

https://github.com/antfu/wenyan-lang-vscode/issues/16 中发现，prefix 用中文时，可用ctrl+space 触发补全窗口（mac 中测试）:  打算接下去在木兰[vsc 插件](https://github.com/MulanRevive/ide-extension-vscode)中开始实践。

个人没听到草蟒项目的性能方面负面反馈。个人认为在有明确需求之后再调研其他方案不迟。

根据[统计](https://www.zhihu.com/question/343846120/answer/810929600), 当前开放的代码行数在十万之内，排除`src/third_party`下的代码应该会更少的多，源码汉化希望在11月前完成。 

中文重命名`mpl2mpl/src/class_init.cpp`中的标识符后初测结果：生成的`out/bin`下输出文件与英文命名源码生成的相同。这样的话，就可以保证在中文重命名标识符过程中的功能正确性了—**直接比较编译输出文件是否相同** 但是, 对字符串的汉化暂时只能倚靠人工检查. 暂时先在独立的汉化文件中记录英中对应字符串, 打算待所有标识符汉化后, 再进行汉化. 60天汉化5万行(下面为[工具](https://dwheeler.com/sloccount/)细测)代码, 还是很有挑战. | 行数 | 目录 | 按语言分行数 | | ------------- | ------------- | ------------- 22338 | maple_ir | cpp=22338 13534 | maple_me |...

[手工翻译方舟编译器源码:尝试重命名标识符与文本, 入口部分](https://zhuanlan.zhihu.com/p/81450947)

开始对[mir_nodes.h](https://gitee.com/Program-in-Chinese/OpenArkCompiler/blob/master/src/maple_ir/include/mir_nodes.h)中的节点类进行汉化. 各操作语义参考[IR设计文档](https://gitee.com/Program-in-Chinese/OpenArkCompiler/blob/master/doc/MapleIRDesign.md). 参考节点类对应操作参考[def文件](https://gitee.com/Program-in-Chinese/OpenArkCompiler/blob/master/src/maple_ir/include/opcodes.def), 共180个操作符左右. [汉化补完中](https://github.com/program-in-chinese/overview/wiki/%E6%96%B9%E8%88%9FIR%E8%8A%82%E7%82%B9%E7%B1%BB%E8%AF%8D%E5%85%B8) [手工翻译方舟编译器源码: IR相关节点类](https://zhuanlan.zhihu.com/p/81979178)

在进一步进行标识符中文化之前, 打算先提取所有标识符并进行统计, 以预估工作量和细化计划. 项目源码在`src/`下, 其中这几个目录下的内容不需提取: - `src/bin`是二进制文件 - `src/deplibs`为依赖库 - `src/third_party`为第三方库 下面是初步设想的提取结果, 每个源码文件(包括.h, .cpp, .def等等)对应一个提取文件. 以较短的[`src/maple_driver/src/file_utils.cpp`](https://code.opensource.huaweicloud.com/HarmonyOS/OpenArkCompiler/file?ref=master&path=src%252Fmaple_driver%252Fsrc%252Ffile_utils.cpp)为例. ### 注释 1-14行为注释, 可直接提取全文. 最好标记为注释, 比如这样(方便二次处理)), **具体格式待定, 请多提意见建议**: ``` 1 2 Copyright (c) [2019]...

这个汉化项目本身的目标有几种可能. 一是作为汉化源码的实战; 二是作为新创中文编程语言的基础. 两者并不矛盾, 参与者可以自行选择着手点. 由于将源代码的标识符汉化将会大大降低参与贡献的门槛, 一个比较可能的定位是***作为方舟编译器官方代码库的一个参与门槛更低的镜像***. 潜在的参与开发者是国内对编译器技术有兴趣, 但又出于某些原因暂时无法参与到主库开发中的开发者. 在非技术优势方面, 想得到一点, 就是作为一些不便向华为贡献代码的开发者, 也许更方便向此库贡献代码. 在此定位下, 意味着要在官方库之外维护一个分支, 而且本分支最好保持功能上与主库的同步. 也就是说, 可以增加功能(比如对中文关键字的支持), 但不可以减少或影响主库的功能. 这点能够保持多久是个未知数, 当然也和项目能够积累的人气有关. 个人来说, 打算短期内着重在汉化方舟源代码本身, 并小结出一套比较实用的汉化源码流程及工具. 现在一个比较大的不定因素是方舟本身的开源程度, 以及测试集的覆盖程度. 当前没有任何自动测试用例, 已在官网提[问题](https://code.opensource.huaweicloud.com/HarmonyOS/OpenArkCompiler/issues/112). 在这种条件下, 只能倚靠手工测试来确保源码汉化后的功能保持不变.