ArcGIS API for JavaScript的翻译中文翻译，其实是翻译个坑。你打开官方文档，翻译看到的翻译是“Map”、“Layer”、翻译“Graphic”，翻译翻译成“地图”、翻译“图层”、翻译“图形”，翻译好像没毛病。翻译可一旦你开始写代码，翻译问题就来了——“FeatureLayer”该叫“要素图层”还是翻译“特征图层”？“PopupTemplate”是“弹窗模板”还是“弹出窗口模板”？每一个术语背后都牵扯着GIS学科几十年的概念体系，翻错了，翻译代码跑不通倒是翻译小事，理解错了架构逻辑才真要命。翻译
我见过最离谱的翻译是把“SpatialReference”直译成“空间参考”。这词在中文GIS圈里其实早有约定俗成的说法——“坐标系”。但官方文档偏不，非要来个“空间参考”。新手看了半天，以为是什么高深的空间哲学概念，其实不就是WGS84、Web Mercator那点事吗？这种翻译不是错，是生硬。生硬到让初学者在概念上绕远路。
再说“Geometry”，翻译成“几何”。单看没问题，可当你处理“Point”、“Polyline”、“Polygon”时，会发现中文GIS教材里早就叫“点、线、面”了。官方翻译成“点、折线、多边形”，一下子把学习的亲切感全打没了。我教过几个学生，他们看英文文档反而比看中文版更快上手，因为英文术语在代码里就是原样，不需要二次映射。
真正让我觉得翻译有意义的，是那些概念性描述。比如“MapView”和“SceneView”，官方译作“地图视图”和“场景视图”。这翻译就挺到位——一个管2D，一个管3D，用“视图”区分开，比直接说“地图”和“场景”清楚得多。还有“WatchUtils”，翻译成“侦听工具”，比“监视工具”更符合前端开发的习惯。这种细节上的拿捏，才显出翻译的价值。
但话说回来，ArcGIS API for JavaScript的翻译难点不在词汇，在句法。英文文档里大量使用被动语态和长从句，比如“A layer that can be used to display feature data from a feature service”，直译成“一个可用于显示来自要素服务的要素数据的图层”，读起来像绕口令。中文GISer更习惯说“用来展示要素服务数据的图层”。翻译者得先把英文句子拆开，重新按中文逻辑组装，这活儿比写代码还费脑。
我自己的经验是，别指望翻译文档能完全替代英文原版。API参考里那些参数说明、返回值类型，看英文反而更快。翻译文档适合用来理解整体架构和设计思路。比如“LayerList”这个控件，英文解释是“A widget that displays a list of layers”，中文翻译成“显示图层列表的控件”，虽然啰嗦，但至少告诉你它是干嘛的。真到用的时候，你还是得去翻示例代码。
所以我的判断是，ArcGIS API for JavaScript的中文翻译，定位应该是“辅助理解工具”，不是“学习主餐”。官方文档的翻译质量在逐年提升，但距离“流畅的中文技术文档”还有距离。你要是真想学这个API，英文原版加示例代码是标配，中文翻译可以用来查漏补缺。至于那些术语翻译的争议，别太较真，代码里跑通了，比什么都强。