返回首页
一周热榜
Twitter/X 最近添加了一个新的请求头，名为 X-XP-Forwarded-For，该请求头由他们自己的基于 WASM 的指纹识别系统生成并加密。这个仓库详细解析了整个流程： https://github.com/dsekz/twitter-x-xp-forwarded-for-header
我们构建了 Tiptap AI Agent，以便轻松将 AI 集成到富文本编辑器中，而无需重建整个前端。
如果您曾尝试在文档编辑器中集成 AI，您可能遇到过以下问题：
- 从复杂的文档结构中提取上下文
- 处理提示输入和流式输出
- 支持 AI 更改的撤销/重做
- 设计接受/拒绝更改的用户界面
- 多人会话状态和冲突
这是一项繁重的工作，而且几乎没有任何部分是特定于模型的。
这个新的 Tiptap 工具包为您提供了一种简洁的方法来定义 AI Agent，这些 Agent 可以根据用户定义的任务读取和编辑富文本。您可以手动、自动或根据结构化输入触发这些 Agent。
它与 OpenAI 或您自己的后端和 LLM 堆栈兼容。构建在 Tiptap 协作功能背后的同一多人引擎之上。
我们还包含了一个 AI 更改扩展，以便用户可以审查并接受/拒绝生成的编辑，就像内容的内置代码审查。
这里有一个实时演示： [https://ai-agent.tiptap.dev/](https://ai-agent.tiptap.dev/)
开发者文档：[https://tiptap.dev/docs/content-ai/capabilities/agent/overview](https://tiptap.dev/docs/content-ai/capabilities/agent/overview)
欢迎提问或分享您正在构建的内容 :-)
为了弥补iPhone最后一个缺失的环节——使其成为一个全面集成的端到端通信和媒体设备——苹果收购威瑞森将是一个改变游戏规则的举措，特别是在如今对联邦监管的信任大幅下降的情况下。<p>作为一家公司，苹果在扩展业务时遇到了瓶颈，拥有一家运营商将为他们提供另一个创新的切入点。
大家好，我喜欢这款应用程序“How We Feel”，它非常棒，我一直想把它放到一个平台上！大多数人会选择Discord，因为它有很好的API和其他功能……但我选择了Telegram，因为我最喜欢它 :3<p>你可以在这里试用：<a href="https://t.me/howwefeel00bot" rel="nofollow">https://t.me/howwefeel00bot</a><p>~ 这是为neon发布的，怀念neon的HN账户 :)
嗨，HN！我们刚刚发布了一个开源的 React 打包插件，使应用程序在构建时支持多语言，而无需修改代码。
React 应用程序的本地化通常需要实现国际化（i18n）框架、将文本提取到 JSON 文件中，并将组件包裹在翻译标签中——基本上是在开始翻译之前，需要重写整个代码库。
我们的 React 打包插件完全消除了这种摩擦。您只需将其添加到现有的 React 应用中，指定所需的语言，它便会自动使您的应用程序支持多语言，而无需触及组件代码的任何一行。
以下是一个展示其工作原理的视频： [https://www.youtube.com/watch?v=sSo2ERxAvB4](https://www.youtube.com/watch?v=sSo2ERxAvB4)。文档可以在 [https://lingo.dev/en/compiler](https://lingo.dev/en/compiler) 找到，示例应用在 [https://github.com/lingodotdev/lingo.dev/tree/main/demo](https://github.com/lingodotdev/lingo.dev/tree/main/demo)。
去年，我们 Twitter 社区的一位开发者告诉我们：“我不想用 `<T>` 标签包裹每个 React 组件，也不想将字符串提取到 JSON 中。我能否只包裹整个 React 应用并使其支持多语言？”
我们最初的反应是：“这不是 React 中 i18n 的工作方式。”但几个小时后，我们发现自己深陷技术难题，开始思考如果这真的是可能的呢？
这个问题促使我们构建了“本地化编译器”——一个用于 React 的中间件，它接入代码库，处理 React 代码的抽象语法树（AST），确定可翻译的元素，将每个上下文边界输入到大型语言模型（LLMs）中，并将翻译结果嵌入构建中，使用户界面在几秒钟内实现多语言支持。
所有操作都在构建时本地进行，保持 React 项目作为真实来源。无需修改代码、提取内容或维护单独的翻译文件，但可以通过 data-lingo-* 属性进行覆盖。
构建这个插件比我们预期的要复杂。除了遍历 React/JS 的抽象语法树外，我们还必须解决一些具有挑战性的问题。我们希望找到一种方法，确定应该一起翻译的元素，以便例如，包裹在 `<a>` 链接标签中的短语不会因为被孤立处理而被误翻译。我们还希望检测内联函数调用，并在编译时代码生成过程中优雅地处理它们。
例如，这整个文本块被我们的本地化编译器识别为一个单一的翻译单元，保留了 HTML 结构和上下文，以供大型语言模型使用。
```
function WelcomeMessage() {
return (
<div>
Welcome to <i>our platform</i>! <a href="/start">Get started</a> today.
</div>
);
}
```
最大的挑战是使我们的编译器与热模块替换（Hot Module Replacement）兼容。这使得开发者可以用英语编写代码，同时即时看到西班牙语或日语的用户界面，这对于捕捉由于文本扩展或收缩而导致的布局问题非常重要，因为不同语言在屏幕上占用的空间不同。
为了提高性能，我们实现了激进的缓存机制，存储 AST 分析结果，并仅重新处理已更改的组件。增量构建在大型代码库中依然保持快速，因为开发者在任何时候只更新有限数量的组件，并且我们对大型语言模型的调用进行了大量并行化。
在大型语言模型出现之前，这种方法在技术上是可行的，但在实际中几乎没有用，因为要获得精确的翻译，仍然需要熟悉产品领域的人类翻译者。然而，现在，借助上下文感知模型，我们可以自动生成不错的翻译。
我们很高兴终于使其准备好投入生产，并与 HN 社区分享这一成果。
运行 `npm i lingo.dev`，查看文档 [lingo.dev/compiler](https://lingo.dev/compiler)，尝试破坏它，并告诉我们您对这种 React 国际化方法的看法！