 | Nixpkgs Architecture Team | 226 Members |
| https://github.com/nixpkgs-architecture, weekly public meetings on Wednesday 15:00-16:00 UTC at https://meet.jit.si/nixpkgs-architecture | 53 Servers |
| Nixpkgs Architecture Team | 226 Members |
| https://github.com/nixpkgs-architecture, weekly public meetings on Wednesday 15:00-16:00 UTC at https://meet.jit.si/nixpkgs-architecture | 53 Servers |
| Sender | Message | Time |
|---|---|---|
| 2 Aug 2022 | ||
 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 | |
 infinisil | We'll have the fourth meeting in a couple minutes in https://meet.jit.si/nixpkgs-architecture. Meeting notes are in https://pad.lassul.us/uIi7xeSJTW6LJUEHulZgVQ. The meeting will also for the first time be live-streamed (and directly uploaded) to the new youtube channel: https://www.youtube.com/channel/UC_BFweJOiukTHdKCr1P0kRQ | 14:58:12 |
| infinisil | I do know there's some people on vacation though, for now it's just me 😅 | 15:01:06 |
| infinisil | Robert Hensing (roberth): tomberek: Are you joining? | 15:01:28 |
| infinisil | Meeting notes are uploaded to https://github.com/nixpkgs-architecture/meetings/blob/master/2022-08-03.md | 16:09:42 |
 FRidh | About language-specific builders and hooks. Some years ago I split up the Python builder into hooks. After that, the same was done for Rust and I think it has been done with some more, but I am not sure. The difficult part with the hooks is that we need to be able to list dependencies between hooks, that is, their order. Furthermore, we have an increasing amount of hook/phase-specific options, for which being able to use structured attributes is needed. I'd say looking at these builders, that this is by and far the largest reason to make a change. It's blocking progress here significantly. And as mentioned in the talk, indeed, there is no need for language-specific builders really. BuildPythonPackage e.g. is primarily just composing hooks. There is just a lot of legacy there. Additionally, in the Python corner, there is quite a desire for using Nix on Windows. Conda is taking more and more steps in the direction of Nix because it solves problems for them. | 16:10:24 |