-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, Elias,
Thank you for sharing your thoughts concerning improving the translation process! In a way, I'm currently the main person when it comes to translating the website (at least). So, I hope that I can help you. Am 13.09.2017 um 04:39 schrieb [email protected]: > I started working on translating the Qubes FAQ to Swedish (since it > was marked as important). However, I have some concerns with > regards to how the file has been split into translatable strings. > > First of all, the split has been done per-sentence, which makes > translation very cumbersome. In many case, there is not a > one-to-one correspondence between the languages. Instead, I'd like > to see the split being on a paragraph-level, at least. I see the problem and I'd like to explain my thoughts below. As you can see here [1], there are reasons why it is preferred to split lines at sentences. Furthermore, Transifex converts each single TXT/MD line into one entity to translate. Thus, there will be one sentence per entity, as you mentioned. Transifex offers the nice feature "Translation Memory Autofill" [2][3] which auto-suggests translations based on earlier translations. Thus, this feature helps translating future versions of the same file more efficiently because in many cases, a newer version brings just small changes. The big hope is that if a sentence in the original/canonical version (en-US) didn't change in the next version then the appropriate translation doesn't need adaptions as well; in this case, the auto-suggestions of "Translation Memory Autofill" can save *a lot of time*. So, it's about time-efficency. But here is the clue: The longer an entity is, the less likely "Translation Memory Autofill" can be used for that entity and the longer-lasting a translator has to re-translate that entity by hand. An example: Let's say you put 20 sentences ("a paragraph") into one line, resulting into one Transifex translation entity. Now, one person translates that entity at once (you can translate an entity only at once!). In the next version, let's say just one sentence in the middle has changed slightly and we obtain a match with the Translation Memory (TM) at less than 100%. Because of that, the suggestion of the TM has to be checked by a human translator as a whole (20 sentences instead of 1!) and at once. This procedure would need probably much more time than having the 20 sentences one-per-entity where 19 100%-matches can be achieved, a translator can skip them quickly and spend time on the "real" change. While this might work in theory, people of some languages could get troubles with that. I don't know a single word in Swedish but I can imagine your difficulties. The question is where to set the boundaries for an entity to translate. People of one language like one paragraph per entity, people of other languages like one sentence per entity etc. It's impossible to serve all languages in advance. What do you think: Can you imagine, even if translating from English into Swedish on per-sentence-level might be cumbersome, that the "Translation Memory Autofill" feature could be helpful (time-saving) when translating newer versions of the same file into Swedish again? If "yes" then I see rather a solution than a problem. > Secondly, the table-of-contents is included in the list of > translatable strings. Not only I have to translate each topic twice > (making sure that I use exactly the same words in both cases), I see the problem. Maybe we could automate creating a TOC without using Jekyll plugins? That would be a nice feature, I think. > I also have to figure out how to specify the intra-document links > so that they will work in the final document. This is something > that I would expect the build process to handle. Currently, we work on many areas needing improvement concerning the translation/localization/internationalization process. While some time ago we suggested to "translate" internal links by adding a language-depending prefix manually [4], we now have the new idea that translators shouldn't touch the links at all while a bot could adapt the links after downloading the translated file from Transifex [5]. > These issues just makes it too cumbersome to continue using this > tool. I totally agree with you. When I started translating the files, I became frustrated and that gave me the power I use for setting up the necessary infrastructure today. > I might consider translating the entire document as a single unit, > but that I suspect that that will cause the versions to diverge > with no easy way to keep them in sync. I agree once more. So, using services like Transifex seems to be a good way in general. Currently, we set up a translation workflow with as many steps as possible being automated. If you like, you may join us. Since this is obviously a topic concerning translation, we highly suggest to continue discussing it on the mailing list "qubes-translation" [6]. For further introduction, please have a look at our first email on that list [7]. Please note that I'm currently very restricted using the Internet. So, please be patient when my reply comes not until next week or something. This will probably last for the next weeks. > Regards, Elias Regards, Tobias Killer [1] https://www.qubes-os.org/doc/doc-guidelines/#markdown-conventions [2] https://docs.transifex.com/setup/translation-memory [3] https://docs.transifex.com/setup/translation-memory/enabling-autofill [4] https://github.com/tokideveloper/qubes-doc/blob/translation-workflow/basics_user/translation-workflow.md [5] https://groups.google.com/forum/#!topic/qubes-translation/N0jj2Eu2x-E [6] https://www.qubes-os.org/mailing-lists/#qubes-translation [7] https://groups.google.com/forum/#!topic/qubes-translation/9IddrqkP-qM -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE9VOPt2yY9xS+XKzULaXvb25AsygFAlm69sYACgkQLaXvb25A sygz5w//TQd8my15GrL4HvkyWSrNti4aL+lj30vbdPjtIv+VpIiHnAcLfUbFCKPS hDpv5Cm/REcV9e9g19pTKyzc9ZXTZuEIWaj1RGusyidrc+VAjUrBav3gp5zefknI asi6fX0jHz6xzKhHQODACl0MslYhQZ2ptoMQLS18PDLOhVfqnLsShnnQD4FSGpP0 UPUr0CSEDMDGR+/Uo48iu4HqE+o/iIlfdP+rIwz8Iy30KCIX2ZXuG9KpNxmRsMF/ ImyJWt6t1FU0PLUXcEZPxZrAOyY11mEVVlyDgEHQIS5+TP5LJ86jJTSPXFPpg0gt Xrr6icjYcivSsSRNbvOzrLGky3zk48I8H//0XTfVTfFZzE6h3hr9yZc7pCTlM6IC tX1vu21z3XufyaqJ1eCteyr7258/aaYDHIQteebXkVndkzhMlt6B9FqChDeWONj8 pREGrTIl8Y82w3Lruj+YZPiqB2enGRagWhnLmk0tjfkbgUvlyrfuqVflPJwv4UND lEXiyyzE78KiWj7yT5oaX8gzz9BTfoClXUD++bycMRY4ObhdVW2gVa1V9E1AYAr+ Hq/EfUkLy+iruNbHHvHG2Tl1qzhxLiVfHMoznkUmKQrKMZvB29lr4L6z4ask7DbP Y9BdLabTANH2q+0C9lakK65nIHkgdF7Ud3PUhtkPqGfxv0OFbcs= =4Opv -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/c452e7ec-4d7d-d2c2-7819-34090f9eee9c%40posteo.de. For more options, visit https://groups.google.com/d/optout.
