Re: [qubes-devel] Transifex translations
11 views
Skip to first unread message
Tobias Killer
Sep 14, 2017, 5:38:34 PM9/14/17
to lok...@gmail.com, qubes-devel, qubes-translation
-----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 lok...@gmail.com:
> 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-----
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 lok...@gmail.com:
> 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-----
Reply all
Reply to author
Forward
0 new messages