返回首页
最新
我们的使用案例：我们的应用程序支持俄语（我们的母语）和英语。我们需要快速、轻松地添加更多语言（应客户要求）。我们的翻译文件一团糟：重复的字符串、使用字符串拼接而非占位符、俄语和英语文件中字符串顺序不同、尾随空格等等。
因此，我编写了一个辅助工具来解决这些问题。现在，添加一种新语言只需40分钟和2美元。这个工具效果很好，我整理了项目并将其作为开源软件发布。
# 主要特点：
翻译新语言时，支持同时使用两种源语言：主要语言（在我们这里是俄语）和次要语言（对我们来说是英语）。次要语言不是严格要求的，但强烈推荐。无论您有多少其他语言，只有主要和次要语言会被发送到LLM上下文中进行翻译。
顺便提一下，上下文还包括附近的字符串和术语表（更多内容见下文），提示设计为LLM首先评论字符串的含义、用途，然后再进行翻译。根据我的测试，这种组合显著提高了翻译质量。
# 关于翻译：
- 支持的格式：目前仅支持JSON（平面和结构化）+ i18next风格的复数形式，但很容易添加新格式。
- 复数形式：支持基数和序数形式。示例：
```json
{
"key_one": "1 file",
"key_other": "{{count}} files"
}
```
- 占位符：${likeJs}、{{doubleCurve}}、{singleCurve} — 您可以轻松添加新格式。每个项目可以设置首选格式。
- 字符串顺序得以保留！这对意义和LLM都很重要。
- 多行字符串：支持\r和\n（可配置）。
- 字符串注释：您可以添加解释，仅存储在应用程序中。默认情况下，由LLM生成。
- 建议翻译：您可以单独提供推荐翻译（例如，来自专业翻译或AI建议）。
- 批量或单个翻译，按语言选择LLM。
- 重用翻译：对于批量翻译，已经翻译的相同字符串会被重用。
- 旧字符串/翻译不会被删除，而是保留在数据库中。这部分覆盖了git中的分支场景，当某些分支已经有新翻译，而某些没有时，确保没有内容丢失。
# 字符串验证
当我们开始认真处理翻译和本地化时，我们迅速意识到我们的翻译文件完全混乱。不仅有未翻译的字符串，还有过时的翻译（主要语言中删除的字符串）、占位符被字符串拼接替代的地方、主要语言（俄语）使用“：”而次要语言（英语）没有的翻译，或者换行符仅存在于其中一个。甚至有些情况下，主要语言有占位符而次要语言忘记了。
现在，所有这些情况都会被检查，任何上传/翻译的字符串如果满足以下条件，将会被标记为警告：
- 翻译字符串为空
- 存在前导或尾随空格
- 字符串包含多个连续空格
- 翻译与主要或次要语言相同（对于电子邮件、API、IP、URL、URI、ID有例外）
- 缺少主要语言中存在的占位符
- 翻译中有一个在主要语言中不存在的占位符
- 主要语言和翻译之间的换行符数量（\r或\n）不同
- 主要语言和翻译之间的冒号数量不同
- 复数值缺失或多余
- 复数值在换行符或冒号上不同
无论验证结果如何，用户都可以手动将字符串标记为已验证，从而实现灵活的过滤和批量翻译控制。
GIF和更多信息请访问GitHub： [https://github.com/XAKEPEHOK/lokilizer](https://github.com/XAKEPEHOK/lokilizer)
我对时间没有概念……
我开始学习网页开发时使用的是PHP，后来转向Ruby on Rails，接着经历了整个React和Next的周期，最近又发现了岛屿架构和Astro以及它那经典的多页面应用（MPA）架构。但我觉得事情可以更简单一些。
Mastro是我试图提炼网页开发本质的尝试。它由四个相互关联的部分组成：
- 一份关于HTML、CSS和JS的入门指南：教你如何在浏览器中构建并发布一个网站到GitHub Pages。
- 一个作为VSCode扩展在浏览器中运行的静态网站生成器。
- 一个不需要打包器、没有客户端JS和冗余的最小化网页框架。
- Reactive Mastro：一个小巧（2.8k min.gz）的客户端响应式GUI库，适用于你现有的MPA或Mastro项目。
目前在生态学和可持续发展领域中，最有趣或最具前景的技术项目有哪些？
我一直在思考——现代浏览器被优化用于解析和运行 HTML、CSS 和 JavaScript。但是，如果有一个浏览器是专门用来加载和运行直接用 WebAssembly 编写的网站呢？<p>这是否会提高性能、启动速度，并减少解析多种格式带来的开销？为什么没有人创建一个默认语言为 WASM 的浏览器呢？<p>这是技术限制、安全问题，还是生态系统缺乏兴趣？<p>我很想听听 HN 社区的看法。
我们开发了一个简单的工具，帮助可持续发展专业人士用通俗易懂的商业术语解释他们的倡议，特别针对财务、运营、人力资源或法律等部门。
这个工具叫做“可持续发展翻译器”。
我们为什么要开发它：
可持续发展团队常常因为使用行话（如范围3、TCFD、再生等）而难以获得内部支持，而其他部门则使用关键绩效指标、利润率和风险等术语。我们希望通过一种快速、有趣且实用的方式来弥补这一差距。
它是如何工作的：
1. 输入任何可持续发展倡议（例如：“我们需要在CSRD下对供应链进行脱碳”）。
2. 选择你要向其推介的部门（例如：财务）。
3. 它将返回一个翻译，用该部门能够理解的语言解释同一点（例如：成本降低、风险缓解、长期盈利能力）。
构建技术：
- Webflow 前端
- Make.com webhook
- OpenAI API（带有部门上下文逻辑的 GPT-4 提示）
为什么推荐给HN？
我们知道很多HN读者正在构建内部工具或应对B2B变革，而这种方法在其他领域（例如人力资源技术、合规、产品战略）也可能有用。
试试看 → [可持续发展翻译器](https://www.leafr.com/sustainababble-translator)
我们非常欢迎反馈、功能建议，甚至是严厉的批评。