 | Nixpkgs Architecture Team | 236 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 | 236 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 | ||
 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 |
| 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 translator(s) would be automatically notified of the event). | 18:37:06 |
 a-kenji | Fluent should be able to do that https://projectfluent.org/ l , but that still would keep the possibility of outdated translations. | 18:40:33 |
| ctem | Thanks for the suggestion! I’ll take a look at it.
If it can be configured to adhere to a strict policy of translation display based on source content (as I described above), then all user-facing translations should be either as up-to-date as the source or altogether invisible. | 18:48:03 |
| ctem | * Thanks for the suggestion! I’ll take a look at it.
If it can be configured to adhere to a strict policy of translation display based on source content (as I described above), then all user-facing translations should be either as up-to-date as the source or altogether invisible (defaulting instead to the source itself). | 18:49:36 |
| 3 Aug 2022 | ||
 nbp joined the room. | 09:39:42 | |
 Xandor Schiefer joined the room. | 12:53:41 | |