我想企业使用FreeCAD作为工具的话，最好是能投入力量，为FreeCAD的功能开发作一些贡献。这样对于技术路线的一致性与持续性，是有益的。

在中国，研究机械发展史的人，不清楚有没有。其实，如果你和一线的加工工人聊聊，会知道，在中国大陆地区。关于机械尺寸的叫法也不相同。如：丝，道。 我想这可能是由于在清朝时期，机械技术从不同的国家传入有关。

另外，中国机制制造技术发达的不同地区，如东北、江浙、湖北、天津等，在培训技术工人时，术语也会有本地文化因素的影响。

在输入框右侧，选择灰色小图标，可以在新窗口中，使用公式时行参数设定。

MacOS用户，建议使用conda环境下的FreeCAD版本。

看你使用的版本号，是Intel架构的MacOS，要注意QT版本升级造成的GUI不能显示的问题。

由于MacOS底层GUI软件架构，发生根本性的改变(Apple的说法，原有GUI层，显示效率低)，而QT还使用原有的软件API，所以会造成显示图形用户接口的问题。

如果你换ARM平台的M1架构，conda版本也会有一些问题。(ARM指令转Intel指令时，有些软件问题)

你说的情况，在conda环境下，是可以解决的，使在安装合适的软件包。这个问题有些专业。

如果动手解决国际化问题，建议从宏观角度考虑清楚后，来真正解决这个问题。 从本人学习FreeCAD近五年的经历来看，FreeCAD所依赖的QT层，操作系统GUI层，Python都在不停向前演进变化着。以MacOS为例，由于其将移动界面与桌面打通的开发战略的实施，MacOS的GUI层的架构完全改变。这造成QT的版本升级遇到问题。有一段时间由于QT没有修正相关问题，造成FreeCAD无法启动GUI界面。 我相信其它如Linux的不同发行版本以及Windows的一些发行版本也会出现一些问题。 现在来分析FreeCAD系统的架构。由于FreeCAD命令行解释器，通过Python与QT层进行交互。由于Py...

关于中文化的核心，其实质是支持多语言的问题。由于对QT没有研究，但如果同realthunder所言，QT内部使用utf16编码来支持多语言编码问题，而当代操作系统默认配置使用utf8编码，那这个问题的解决，还是比较复杂，是需要通过编写一些函数，作为库函数，引入FreeCAD项目中来解决支持多种语言的问题。 从操作系统的视解来看，这是由于不同进程所需的运行环境，使用不同的字符编码方案，产生对于同一字节顺序流，在不同的字符编码转换表中查询时，得到不同的值，在将该值提交给GUI层后，被解释为不同的字符显示图样，而造成的结果。这与Linux发展早期(2000年左右)支持多语言的情况相同。如Linux终...

关于字符编吗问题，个人理解，其核心是计算环境的进程运行环境问题，如果对于操作系统内核，进程以及shell等计算机基本原理概念有所理解话，可以从整个系统的关系中来找到解决这个问题的方法。

Python只是与shell相同的一个语言解释器，也是操作系统下的一个进程，因此，个人理解，期还不是最为基础的一个软件组件。根据Unix系统设计哲学，所有问题的解决，都可以通过引入中间层来处理。这样的处理方法，对于系统来说，有足够的灵活性，还兼具系统的健壮性。因为每层都可以被其它更精细的软件层进行替换。这个处理问题的方法，应在统编写软件工程时，随着遵守。

看了相关讨论，谈一下个人看法。 建议编写一个处理不同编码方案的函数，来解决中文化的问题，而不是简单使用将latin1字符编码方案替换成utf8这种方式。 提出以上意见的原因，是由于FreeCAD是一个开放平台，还有其它国家的不同语言编码方案需要使用，且除了utf8字符编码方案之外，还有utf16等不同的方案。只通过替换latin1到utf8方式，进行编码表扩展，只是将一个问题，转换成另一个问题。 另外，对于使用非utf8编码方案的语言来说，utf8编码方案过于繁杂。 如果使用一个函数，通过不同的编码方案作为参数，来进行字符编码的转换，可以更为灵活的解决多语言平台对于FreeCAD的使用用户界面...

主要原因可能是QT的问题。不一定是Python。
可能你安装环境中,QT与Python之间的中间件软没有安装。

关于零件设计的哲学 个人建议：最好不要使用所谓"组合"方式设计零件。因为我们目前的生产还主要是“减材制造"方法。如:"车，磨，铣“等，都是去除材料方式来制造零件。 目前如三维打印方式的所谓"增材制造"技术还在发展，不是主流，所以你使用"组合"思想设计零件，一方面，计算机资源占有历害；再一方面，设计出来的产品，如加工制造，还比较麻烦。 另外，在零件的制图过程中，据美国工程师的建议，一张图纸，只标注一方面的参数，将不同参数在不同的图纸上标注，有助于工程设计文件管理。因此，如果设计产品过于复杂，后期制造、管理方面，会引起...