HackerURLs

一次又一次被重新发现的经典。

同一个链接,相隔一年以上,一次又一次被人重新发现、再次冲上 Hacker News 首页。能经受住这种时间检验的,大多是值得一读再读的文章。每篇附中文标题,讨论最热的那些再加上中文导读和高赞评论翻译。

从名人堂开始
  • 4,700+篇经过时间检验的经典

Hall of fame

名人堂

在经典库里看全部精选

上首页次数最多、而且有中文导读的 30 篇。时间轴上每个黑点是一次上首页,空心点是一次没冲上去的投稿。

  1. 正在载入经典…

Archive

经典库

按第一次上首页的年份分布,点柱子筛选。

排序

    About

    这些经典是怎么挑出来的

    1. 01

      合并同一个链接

      读取 Hacker News 自 2006 年以来的全部链接投稿,把 http/https、www、跟踪参数等写法不同的同一篇文章合并成一条。

    2. 02

      只留经得起时间的

      同一链接至少两次拿到 50 分以上(约等于上首页),而且两次相隔一年以上;再由 AI 剔除状态页、产品首页和新闻事件。

    3. 03

      写导读、译评论

      上首页次数最多的 2,000 篇配上中文导读、"为什么经久不衰",并精选翻译 HN 高赞评论。导读由 AI 生成,可能有误。

    编程与软件工程search.cpan.org

    本地化恐怖故事:它可能发生在你身上

    A Localization Horror Story: It Could Happen to You

    2次上首页
    4年跨度
    741累计得分
    336条评论

    2011 — 2015,它一次次回到首页

    黑点是上首页(≥ 50 分)的那次投稿,空心点是没冲上去的投稿,点越大分数越高。

    导读

    这是 Perl 本地化模块 Locale::Maketext 文档中一篇著名的长文,由两位语言学家撰写,通过一个虚构的本地化灾难故事,系统讲解了软件国际化中的陷阱:复数形式、性别、格变化、数字格式等在英语之外的语言中远比想象复杂。文章虽以 Perl 为背景,但内容与具体语言无关。

    为什么经久不衰:它把本地化的真实复杂度讲得深入浅出,十几年后仍是工程师理解 i18n 问题的最佳入门读物之一。

    关键词 国际化本地化软件工程语言学

    HN 评论精选

    文章质量高,内容不限于 Perl,值得所有开发者阅读。

    一篇详细、有洞见且写得很好的文章,讲软件国际化中的坑和复杂性,作者是两位语言学家。即使与 Perl 无关也非常值得一读。

    thomas11查看英文原文

    A detailed, insightful and well-written article on the pitfalls and complications of internationalization in software, written by two linguists. Very good read, independent of Perl.

    字符串生成必须放在有完整上下文的最内层代码,库不应擅自拼用户可见文本。

    多年经验总结出的一条架构建议:不要假设可以在没有完整上下文的情况下生成任何用户可见的字符串。设计可本地化的应用时,必须允许把字符串生成委托给最贴近该字符串的具体代码,因为只有那里才有正确的上下文。库的深层代码不能自行生成字符串,最终应用的开发者要能按场景覆盖它们。相信我,我是波兰人——很少有语言像波兰语这么疯狂,不信可以看看这本 252 页的波兰语数词语法入门。

    jwr查看英文原文

    That is a very good article. One architectural takeaway suggestion I've learned over the years, which is not obvious when reading that article: "You should not assume that you can generate any part of any string visible to the user without the full context." Whenever you design a localizable application, it isn't enough to provide a string that can be translated. You have to allow for delegation to the most specific piece of code dealing with the string, because only that piece of code will have the appropriate context to properly produce the string. This means your code can't just assume it can generate strings somewhere deep inside the guts of a library. The programmer writing the final application that uses your library needs to be able to generate/override those strings on a per-case basis in the actual code that displays them to the user. The strings might be different between two UI windows. Trust me, I know. I'm Polish. Few languages are as insane as my native tongue. If you don't believe me, take a peek at this concise 252-pages long introduction to Polish numerals: http://www.amazon.com/Liczebnik-grammar-numerals-exercises-language/dp/832420234X

    缺乏上下文的字符串翻译必然出错,本地化必须提供语境。

    我曾在日本为一部日本大牌功能手机做校对。流程是:日本人先用很差的英语把日文翻成英文,再让只拿到字符串、毫无上下文的译者翻成其他语言。结果一半以上的翻译都因缺乏上下文而出错——比如有人把“垃圾回收日”翻成了“倒霉的一天”。我们经常要问“删除一个……什么?我需要知道阴阳性”,但代码已定稿改不了,只能做 %n item(s) 这种丑陋处理。

    eloisant查看英文原文

    When I was in Japan I did proof reading for a Japanese feature phone. A major Japanese brand, actually. That was really comical. There was an Australian guy for English, an German guy, an Italian lady, and me for French. What they did prior to the meeting is: * translate from Japanese to English by Japanese people with a poor English level (maybe the software engineers actually) * translate from weird English to other languages by translators who had only the strings, absolutely no context. In the meeting we had all the strings, and one person from the manufacturers who had access to the "super-confidential" unreleased device. More than half of the translations were off because of lack of context. The French guy actually translated "Garbage day" to something like "Shitty day", apparently he thought that was a way to mark in your calendar that you had a really bad day. Pretty often we had sentences like "delete one", and invariably one of us had to ask "One what? I need to know if it's masculine/feminine/neutral". Of course they didn't prepare to that, it was too late to change the code, so they made us do ugly things like "%n item(s)". Also the Australian guy was loosing faith into humanity: - That sentence, it's completely wrong, it just doesn't mean anything in English. People will just go "WTF?" when they read that - We're not allowed to change the English strings, they're already validated - .....

    推荐 Grammatical Framework:基于语言 AST 自动处理各语言的语法变化。

    据我所知,几乎没人使用的最佳本地化工具是 Grammatical Framework——一种带依赖类型系统的高阶函数式语言,专为操作语言 AST 设计,其资源库覆盖 29 种语言的形态和基础语法。只要有了语言无关的 AST,就能自动生成所有支持语言的正确时态、性别和屈折变化。前期学习成本高,但能免费获得可复现的高质量多语言输出,非常值得。

    dkbrk查看英文原文

    As far as I can tell, the best tool for localisation almost nobody is using is http://www.grammaticalframework.org/. Licensing is a mix of GPL, BSD and MIT pieces. It's a high-level functional programming language with a dependent type system specialised for operating on language ASTs. It's resource library, to quote "covers the morphology and basic syntax of currently 29 languages: Afrikaans, Bulgarian, Catalan, Chinese, Danish, Dutch, English, Estonian, Finnish, French, German, Greek, Hindi, Japanese, Italian, Latvian, Maltese, Nepali, Norwegian bokmål, Persian, Polish, Punjabi, Romanian, Russian, Sindhi, Spanish, Swedish, Thai, Urdu." In essence, once it has the language-independent AST, it can produce output in all its supported languages with the correct tenses, genders, inflections, etc. It also seems to have tools for assisted parsing, so you could have an english document and interactively parse it into the correct AST. In addition, the text can be parameterised semantically, so if you changed the gender of a person, that could propagate to all the correct locations and update the translations as required. While it seems the upfront cost may be quite high in having to learn such a complex system, I think the benefits of having reproducible, high-quality outputs into n languages for free could make this highly advantageous in many applications.

    历次讨论

    同类还值得读

    1. 开源应用架构

      The Architecture of Open Source Applications

      《开源软件架构》(AOSA)是一本在线免费书,邀请知名开源项目的作者亲自剖析其内部设计,涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。

      编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选
    2. 编程语言简史:简短、不完整且多半错误

      A Brief, Incomplete, and Mostly Wrong History of Programming Languages

      一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章,用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。

      编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.com
    3. SQLite 是如何测试的

      How SQLite is tested

      SQLite 官方文档页,系统介绍 SQLite 的测试体系:多种测试方法(TCL 测试、模糊测试、回归测试、静态分析等)和海量测试用例,展示了这个小型开源项目如何靠极致测试获得…

      编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选
    4. 高级编程语言(2009)

      Advanced programming languages (2009)

      Matt Might 的经典文章,按用途推荐“高级编程语言”:如果追求就业就选主流语言,如果追求表达力、学术研究或创业,则推荐 Haskell、OCaml、Scala 等函数式语…

      编程与软件工程上首页 8 次 · 2009–2022matt.might.net
    5. 我的 Forth 与栈机器经历

      Yosefk - My history with Forth & stack machines

      作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程:既赞叹其简洁优雅、代码量小、可自举的优点,也坦率指出栈操作在实际编程中的痛苦,以及 Forth 社区文化中的问题。

      编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选

    打赏支持

    打赏二维码

    觉得有用,请作者喝杯咖啡。

    WeChat

    关注向阳乔木

    微信公众号「向阳乔木推荐看」

    微信公众号「向阳乔木推荐看」二维码

    微信扫一扫;在微信里打开本页时,长按二维码识别。