 | Nixpkgs Architecture Team | 233 Members |
| https://github.com/nixpkgs-architecture, weekly public meetings on Wednesday 15:00-16:00 UTC at https://meet.jit.si/nixpkgs-architecture | 52 Servers |
| Nixpkgs Architecture Team | 233 Members |
| https://github.com/nixpkgs-architecture, weekly public meetings on Wednesday 15:00-16:00 UTC at https://meet.jit.si/nixpkgs-architecture | 52 Servers |
| Sender | Message | Time |
|---|---|---|
| 2 Aug 2022 | ||
 infinisil | I like the idea of using deepl as a starting point | 17:34:20 |
| infinisil | Maybe it should be marked as "machine-translated" though | 17:34:32 |
| infinisil | And when an actual person goes and checks/corrects it, that label could be removed | 17:35:02 |
 ctem | I see. So the DeepL recommendation was exclusive to the manuals, which otherwise would require full, up-to-date translations. | 17:35:09 |
 Wanja Hentze | while I'm 100% behind application localization (after all, english is not my first language and I probably wouldn't have started using computer if they were all in english), developer-only docs are a different story | 17:36:51 |
| Wanja Hentze | do we expect people who don't know english to be able to contribute back, including docs? if so, and if the authoritative version of docs remains english, how do we do that? deepl backwards also? | 17:37:28 |
| Wanja Hentze | though the manual is kind of both - it also targets day to day NixOS users, not just developers | 17:39:39 |
| ctem | In reply to @whentze:matrix.org This exposes the more fundamental issue that contributions have to be prepared in a language that maintainers can understand. As with the typical statement found in legal documentation—"In case of discrepancy between the English version of these Terms and any translated version, the English version shall prevail"—documentation translation contributions (e.g., via Weblate) tends to be based on an ‘honor system’ because maintainers can’t confirm accuracy with complete certainty. For that reason, I think it’s reasonable to expect contributors to have a level of fluency in the project’s dominant language. | 18:10:53 |
| Wanja Hentze | I tend to agree | 18:11:41 |
| ctem | In reply to @whentze:matrix.org* This exposes the more fundamental issue that contributions have to be prepared in a language that maintainers can understand. As with the typical statement found in legal documentation—"In case of discrepancy between the English version of these Terms and any translated version, the English version shall prevail"—documentation translation contributions (e.g., via Weblate) tend to be based on an ‘honor system’ because maintainers can’t confirm accuracy with complete certainty. For that reason, I think it’s reasonable to expect contributors to have a level of fluency in the project’s dominant language. | 18:11:46 |
 K900 | FWIW, as someone who's bilingual in a "weirder" language (specifically Russian), machine translation is awful | 18:12:30 |
| K900 | Yes, that includes DeepL | 18:12:36 |
| ctem | I’ve had similar experiences with Japanese. | 18:13:18 |
| K900 | And when dealing with documentation that gives you all kinds of exciting ways to hose your system, it's not what you want | 18:13:21 |
| K900 | Microsoft has been trying to do machine translation on MSDN for years now | 18:13:35 |
| K900 | They even have a separate dataset trained specifically on programming manuals | 18:13:43 |
| K900 | And it still gets things objectively wrong | 18:13:50 |
| K900 | So if our options are machine translate the docs or don't translate at all, I am firmly on the don't translate at all side | 18:14:17 |
| K900 | Because we will not be able to actually validate the output | 18:14:31 |
| K900 | And people will hose their systems | 18:14:35 |
| K900 | Again, I don't mean hard to read, or weirdly worded or whatever, I have yet to see a machine translator that gets technical documentation from English to Russian without actual, serious distortion of meaning | 18:15:39 |
| K900 | I think it's better with closer related languages like English and French or whatever | 18:16:02 |
| K900 | (I did take a few years of French and German both in middle school but I am in no way qualified to comment here) | 18:16:20 |
 Rick (Mindavi) | In reply to @k900:0upti.meYeah, that's easy enough. If the grammar doesn't match though, or general conventions... | 18:16:46 |
| K900 | But with Russian I absolutely stand by the fact that it's better to have no docs than machine translated docs | 18:16:57 |
| Rick (Mindavi) | Not sure if it makes sense to tackle that here, iny opinion there are more fundamental things to tackle... But I'm Dutch so 🤷 | 18:18:08 |
| Rick (Mindavi) | * Not sure if it makes sense to tackle that here, in my opinion there are more fundamental things to tackle... But I'm Dutch so 🤷 | 18:18:19 |
| ctem | In reply to @k900:0upti.meI take this point seriously. @qyliss seemed to suggest that the gettext approach was inappropriate for full length prose manuals (forgive me if I read too far into the comment), but I wonder if there isn’t a standardized way to similarly translate longer, technical documents, e.g., in semantic blocks (such as paragraphs or even sections) that impart complete thoughts, such that human-contributed (or reviewed from machine-translated suggestions) are displayed where available and otherwise default to the authoritative original. If the authoritative original of a given semantic block later changes (even by a single character), all translations of that block would be automatically disabled (and the contributors are automatically notified of the event). | 18:34:09 |
| ctem | In reply to @k900:0upti.me* I take this point seriously. @qyliss seemed to suggest that the gettext approach was inappropriate for full length prose manuals (forgive me if I read too far into the comment), but I wonder if there isn’t a standardized way to similarly translate longer, technical documents, e.g., in semantic blocks (such as paragraphs or even sections) that impart complete thoughts, such that human-contributed (or reviewed from machine-translated suggestions) translations are displayed where available and otherwise default to the authoritative original. If the authoritative original of a given semantic block later changes (even by a single character), all translations of that block would be automatically disabled (and the contributors are automatically notified of the event). | 18:35:18 |
| ctem | * I take this point seriously. @qyliss seemed to suggest that the gettext approach was inappropriate for full length prose manuals (forgive me if I read too far into the comment), but I wonder if there isn’t a standardized way to similarly translate longer, technical documents, e.g., in semantic blocks (such as paragraphs or even sections) that impart complete thoughts, such that human-contributed (or reviewed from machine-translated suggestions) translations are displayed where available and otherwise default to the authoritative original. If the authoritative original of a given semantic block later changes (even by a single character), all translations of that block would be automatically disabled (and the block’s author(s) would be automatically notified of the event). | 18:36:33 |