On 05/27/2010 03:27 AM, Eric "Sparks" Christensen wrote:
The easy way to do this is to publish all documents in all languages. That way the guide would be available in English no matter if the text was translated or not.
Of course this would mean partial translations would be published which, in my opinion, are better than no translation.
Actually, we can do it slightly smarter than that; Publican has an option for exactly this use-case: the "ignored_translations" parameter in the publican.cfg file.
For example, if "ignored_translations" in the Installation Guide was set for Italian and Spanish, then when you built the book for those languages, it would ignore any PO files available and just build the book using the English strings. For very incomplete translations, I think this is better than a book mostly in English with a paragraph here-and-there in a translated language, but translation teams might have other ideas?
I can see two downsides though:
1. It seems wasteful to have multiple copies of exactly the same content stored on the server. It will also make maintaining the site much more difficult if the site image (web.git) grows to something like 40 times its current size. (although this will no longer be a problem when we move to a fully automated publishing system shortly)
2. At the moment, when you see a book in a language menu, you know that it is translated. The situation is not so bad for widely translated languages, but for less widely translated languages, users will click on links and most will be in English; they might not even discover that *any* books have been translated into their language, so the hard work of the translation team gets lost in a sea of English.
In case translators have not realised, the menus are now all automatically generated, so it's not possible for us to manually add links any more. I will ask the Publican developer today whether some kind of "cross linking" is possible. Even if this becomes possible, it would solve problem 1 but not problem 2.
I wonder if a better solution would be for me to add a prominent notice to the "Welcome" page to tell visitors "to see a full list of all documentation, change the language to English"?
Cheers Rudi
On Wed, May 26, 2010 at 9:41 PM, Ruediger Landmann r.landmann@redhat.com wrote:
- At the moment, when you see a book in a language menu, you know that
it is translated. The situation is not so bad for widely translated languages, but for less widely translated languages, users will click on links and most will be in English; they might not even discover that *any* books have been translated into their language, so the hard work of the translation team gets lost in a sea of English.
Document titles could and should be displayed in the native language, and English titles will then stand out.
I wonder if a better solution would be for me to add a prominent notice to the "Welcome" page to tell visitors "to see a full list of all documentation, change the language to English"?
In the meantime, definitely.
Regards, Miloš
On 05/27/2010 07:13 AM, Miloš Komarčević wrote:
On Wed, May 26, 2010 at 9:41 PM, Ruediger Landmann r.landmann@redhat.com wrote:
- At the moment, when you see a book in a language menu, you know that
it is translated. The situation is not so bad for widely translated languages, but for less widely translated languages, users will click on links and most will be in English; they might not even discover that *any* books have been translated into their language, so the hard work of the translation team gets lost in a sea of English.
Document titles could and should be displayed in the native language, and English titles will then stand out.
Actually, that's a good point!
Publican has only recently gained the ability to display the translated titles of documents in the menu rather than the English titles (only after I had already built the site!) Changing the titles the "proper" way involves uninstalling and reinstalling each document (around 300 of them...) so I'm investigating how I can fix this without having to do that :)
I wonder if a better solution would be for me to add a prominent notice to the "Welcome" page to tell visitors "to see a full list of all documentation, change the language to English"?
In the meantime, definitely.
OK -- I'll get this done today. Thanks for the feedback :)
Cheers Rudi
2010/5/26 Ruediger Landmann r.landmann@redhat.com:
On 05/27/2010 03:27 AM, Eric "Sparks" Christensen wrote:
The easy way to do this is to publish all documents in all languages. That way the guide would be available in English no matter if the text was translated or not.
Of course this would mean partial translations would be published which, in my opinion, are better than no translation.
Actually, we can do it slightly smarter than that; Publican has an option for exactly this use-case: the "ignored_translations" parameter in the publican.cfg file.
For example, if "ignored_translations" in the Installation Guide was set for Italian and Spanish, then when you built the book for those languages, it would ignore any PO files available and just build the book using the English strings. For very incomplete translations, I think this is better than a book mostly in English with a paragraph here-and-there in a translated language, but translation teams might have other ideas?
It's ok with 85% or more. Books with less than that, in English. It was discussed before.
I can see two downsides though:
- It seems wasteful to have multiple copies of exactly the same content
stored on the server. It will also make maintaining the site much more difficult if the site image (web.git) grows to something like 40 times its current size. (although this will no longer be a problem when we move to a fully automated publishing system shortly)
No. Just the link.
- At the moment, when you see a book in a language menu, you know that
it is translated. The situation is not so bad for widely translated languages, but for less widely translated languages, users will click on links and most will be in English; they might not even discover that *any* books have been translated into their language, so the hard work of the translation team gets lost in a sea of English.
A new user would open his/her firefox. It will automatically go to his/her locale, es-ES in my case. The page for F13 will not show all the books. And we have a good set of books, that even though in English, they will surely cover his/her problem. I don't want him/her to think that we only have the books shown in that page. The titles are in English, he/she might think that those are all the books we have. We have more books than other linux distributions.
In case translators have not realised, the menus are now all automatically generated, so it's not possible for us to manually add links any more. I will ask the Publican developer today whether some kind of "cross linking" is possible. Even if this becomes possible, it would solve problem 1 but not problem 2.
Would you please ask him to generate a .pot file for a chapter? So, if there are n chapters there will only be n .pot files. The huge number of .pot files isn't helpful for translation. It even makes Tx's life harder. It would also prevent string repetition. To see this issue, just run "msgfmt -c *.po" in es-ES, for example.
I wonder if a better solution would be for me to add a prominent notice to the "Welcome" page to tell visitors "to see a full list of all documentation, change the language to English"?
Probably, but I prefer the link at the left. The user's attention will be there.
thank you for your time, Rudi.
kind regards
Domingo Becker
On 05/27/2010 10:29 AM, Domingo Becker wrote:
I can see two downsides though:
- It seems wasteful to have multiple copies of exactly the same content
stored on the server. It will also make maintaining the site much more difficult if the site image (web.git) grows to something like 40 times its current size. (although this will no longer be a problem when we move to a fully automated publishing system shortly)
No. Just the link.
Yeah, unfortunately just not possible right now. Uploading the book multiple times is the only way to do it right now :(
- At the moment, when you see a book in a language menu, you know that
it is translated. The situation is not so bad for widely translated languages, but for less widely translated languages, users will click on links and most will be in English; they might not even discover that *any* books have been translated into their language, so the hard work of the translation team gets lost in a sea of English.
A new user would open his/her firefox. It will automatically go to his/her locale, es-ES in my case. The page for F13 will not show all the books. And we have a good set of books, that even though in English, they will surely cover his/her problem. I don't want him/her to think that we only have the books shown in that page. The titles are in English, he/she might think that those are all the books we have. We have more books than other linux distributions.
Yes, we agree that this is one side of the problem. I was just expressing the other side -- presenting a list of books to users as if they were in users' own languages, but when they click on a link, they discover that the book is in English. They go back to the menu and try another book, and it's in English again. And another book -- still English!
When I settle on a solution for presenting the titles of the books in the translated language, this part of the problem should go away :) Title in menu in English = book in English. Title in menu in Spanish = book in Spanish :) Nobody should be surprised :)
In case translators have not realised, the menus are now all automatically generated, so it's not possible for us to manually add links any more. I will ask the Publican developer today whether some kind of "cross linking" is possible. Even if this becomes possible, it would solve problem 1 but not problem 2.
Would you please ask him to generate a .pot file for a chapter? So, if there are n chapters there will only be n .pot files. The huge number of .pot files isn't helpful for translation. It even makes Tx's life harder. It would also prevent string repetition. To see this issue, just run "msgfmt -c *.po" in es-ES, for example.
This issue is unrelated to Publican; I'll post an explanation in a separate thread.
I wonder if a better solution would be for me to add a prominent notice to the "Welcome" page to tell visitors "to see a full list of all documentation, change the language to English"?
Probably, but I prefer the link at the left. The user's attention will be there.
Oh yes, I think we all agree that this is best :) It's just a case of working out how to make it happen :)
thank you for your time, Rudi.
And thank you for your hard work and perseverance.
I want to extend a special thank you to Domingo and Daniel from the Spanish team -- for F13 they have really been fighting hard to fight off technical problems with the Installation Guide in Transifex, and in one very tragic incident, lost a lot of their work. I'm sure that everyone reading this can understand the horror of that situation :(
Still, they just picked up with what they had left and kept going.
Thanks guys -- your dedication is truly inspiring!
Cheers Rudi
2010/5/26 Ruediger Landmann r.landmann@redhat.com:
On 05/27/2010 10:29 AM, Domingo Becker wrote:
I can see two downsides though:
- It seems wasteful to have multiple copies of exactly the same content
stored on the server. It will also make maintaining the site much more difficult if the site image (web.git) grows to something like 40 times its current size. (although this will no longer be a problem when we move to a fully automated publishing system shortly)
No. Just the link.
Yeah, unfortunately just not possible right now. Uploading the book multiple times is the only way to do it right now :(
:-s
- At the moment, when you see a book in a language menu, you know that
it is translated. The situation is not so bad for widely translated languages, but for less widely translated languages, users will click on links and most will be in English; they might not even discover that *any* books have been translated into their language, so the hard work of the translation team gets lost in a sea of English.
A new user would open his/her firefox. It will automatically go to his/her locale, es-ES in my case. The page for F13 will not show all the books. And we have a good set of books, that even though in English, they will surely cover his/her problem. I don't want him/her to think that we only have the books shown in that page. The titles are in English, he/she might think that those are all the books we have. We have more books than other linux distributions.
When I settle on a solution for presenting the titles of the books in the translated language, this part of the problem should go away :) Title in menu in English = book in English. Title in menu in Spanish = book in Spanish :) Nobody should be surprised :)
It would be great this way.
And thank you for your hard work and perseverance.
I want to extend a special thank you to Domingo and Daniel from the Spanish team -- for F13 they have really been fighting hard to fight off technical problems with the Installation Guide in Transifex, and in one very tragic incident, lost a lot of their work. I'm sure that everyone reading this can understand the horror of that situation :(
As Forrest Gump said, ... [1] I can't reproduce it here. :-)
[1] http://es.wikipedia.org/wiki/Forrest_Gump#Forrest_hace_historia_pol.C3.ADtic...
k.r.
Domingo Becker
On 05/27/2010 10:29 AM, Domingo Becker wrote:
Would you please ask him to generate a .pot file for a chapter? So, if there are n chapters there will only be n .pot files. The huge number of .pot files isn't helpful for translation. It even makes Tx's life harder. It would also prevent string repetition. To see this issue, just run "msgfmt -c *.po" in es-ES, for example.
As I said, I'm answering this is a separate thread because it's quite a separate (and complicated!) issue from how untranslated books are linked on the docs website...
The problem here has nothing to do with Publican and everything to do with the XML structure of individual books. As you probably know, the Installation Guide is highly unusual in this regard; /most/ books do indeed have a single PO file per chapter (or at least, per major section). The peculiar structure of the Installation Guide is due to the interaction of two factors:
The first factor is the requirement of DocBook XML that the ID of a node must be unique in the entire book. For example if you have:
<chapter id="Graphical_Installation"> <title>The Graphical Installation Process</title> <para></para> <para></para> <para></para> <para></para> </chapter>
You can only have this chapter *once* in a <book>. Alternatively, if you leave out the "id" attribute from the <chapter> tag, you cannot link to the chapter from elsewhere in the book.
The second factor is the desire to reduce overall writer and translator load by sharing as much content as possible between two Red Hat Enterprise Linux books and two Fedora books. When combined with the above restriction, this creates a special problem for the Installation Guide, where we have many many identical paragraphs that are shared both *inside* the Red Hat Enterprise Linux versions of the book, and *between* the Red Hat Enterprise Linux versions and Fedora versions. In fact, in eight places! :
Fedora Installation Guide Fedora Installation Quick Start Guide x86 part of the Red Hat Enterprise Linux 5 Installation Guide PowerPC part of the Red Hat Enterprise Linux 5 Installation Guide System z part of the Red Hat Enterprise Linux 5 Installation Guide x86 part of the Red Hat Enterprise Linux 6 Installation Guide PowerPC part of the Red Hat Enterprise Linux 6 Installation Guide System z part of the Red Hat Enterprise Linux 6 Installation Guide
(note that we only really maintain a single "latest" version of the Fedora books, but must actively maintain separate Red Hat Enterprise Linux 5 and Red Hat Enterprise Linux 6 books; if we had more resources, we really should maintain two separate versions of each of the Fedora books too, to reflect the two versions of Fedora current at any time)
These eight places all contain a similar set of paragraphs but not every paragraph is included in every one of those eight places or are exactly the same in all eight places -- the places are *mostly* the same but not *completely* the same. We get around it this way:
<book> <part id="Installation-x86"> <title>Installing on x86 architecture</title> <chapter id="Graphical_Installation-x86"> <xi:include title-1> <xi:include para-1> <xi:include para-2> <xi:include para-3> <xi:include para-4> </chapter> ...many other chapters here... </part> <part id="Installation-ppc"> <title>Installing on PowerPC architecture</title> <chapter id="Graphical_Installation-ppc"> <xi:include title-1> <xi:include para-1> <xi:include para-2> <para>PowerPC has an extra paragraph here</para> <xi:include para-3> <xi:include para-4> </chapter> ...many other chapters here... </part> <part id="Installation-s390"> <title>Installing on IBM System z architecture</title> <chapter id="Graphical_Installation-s390"> <xi:include title-1> <xi:include para-1> <xi:include para-2> <para>This para is different for System z</para> <xi:include para-4> </chapter> ...many other chapters here... </part> </book>
Each para that is used more than once is contained in a single XML file and therefore a single POT and a single PO file per language.
A single PO file for any of these chapters would significantly increase the amount of string repetition, not decrease it. It also means that any correction to a single paragraph must happen in up to eight different XML files and up to eight different PO files *per language*.
In saying all this, I'm certainly not trying to deny that structuring the book this way also creates a different set of new problems for translators. I'm just trying to explain the reasons behind the design decision. I also acknowledge that the bigger problem of how these books interact with their Red Hat Enterprise Linux counterparts (and how the sections within the Red Hat Enterprise Linux books interact with each other) might not have been clear up to now for those who have only seen the Fedora books. Anyone who's interested in seeing the interaction more closely should visit: http://www.redhat.com/docs/manuals/enterprise/
Thanks Domingo for the excellent question -- I'm sure this is something that lots of people have wondered about when they confront the maze of the Installation Guide...!
Cheers Rudi
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/26/2010 04:41 PM, Ruediger Landmann wrote:
On 05/27/2010 03:27 AM, Eric "Sparks" Christensen wrote:
The easy way to do this is to publish all documents in all languages. That way the guide would be available in English no matter if the text was translated or not.
Of course this would mean partial translations would be published which, in my opinion, are better than no translation.
Actually, we can do it slightly smarter than that; Publican has an option for exactly this use-case: the "ignored_translations" parameter in the publican.cfg file.
For example, if "ignored_translations" in the Installation Guide was set for Italian and Spanish, then when you built the book for those languages, it would ignore any PO files available and just build the book using the English strings. For very incomplete translations, I think this is better than a book mostly in English with a paragraph here-and-there in a translated language, but translation teams might have other ideas?
So we would have to manually enter all the languages that we don't want translated?
I can see two downsides though:
- It seems wasteful to have multiple copies of exactly the same content
stored on the server. It will also make maintaining the site much more difficult if the site image (web.git) grows to something like 40 times its current size. (although this will no longer be a problem when we move to a fully automated publishing system shortly)
Well, we should plan on that kind of space, anyway. If (when) all the guides get completely translated we'll need that kind of storage.
- At the moment, when you see a book in a language menu, you know that
it is translated. The situation is not so bad for widely translated languages, but for less widely translated languages, users will click on links and most will be in English; they might not even discover that *any* books have been translated into their language, so the hard work of the translation team gets lost in a sea of English.
Maybe you tint the non-translated versions down to a gray. You can see them but they don't stand out like the translated versions.>
Cheers Rudi
- --Eric
Eric "Sparks" Christensen wrote:
Maybe you tint the non-translated versions down to a gray. You can see them but they don't stand out like the translated versions.>
Or perhaps add the words '(English Version)', the way it is seen on the Red Hat Documentation website:
http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/es-ES/index.html
hth
regards Runa
why this is not english version ? it´s too hard to translate into indonesia
On Wed, Jun 2, 2010 at 12:07 PM, Runa Bhattacharjee runab@redhat.comwrote:
Eric "Sparks" Christensen wrote:
Maybe you tint the non-translated versions down to a gray. You can see
them
but they don't stand out like the translated versions.>
Or perhaps add the words '(English Version)', the way it is seen on the Red Hat Documentation website:
http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/es-ES/index.html
hth
regards Runa
-- blog: http://arrbee.wordpress.com
irc: runa on Red Hat arrbee or runa_b on Freenode -- trans mailing list trans@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/trans
Okta Purnama Rahadian wrote:
why this is not english version ? it�s too hard to translate into indonesia
The default page *is* in English:
http://www.redhat.com/docs/manuals/enterprise/
I used the Spanish page as an example relevant to the conversation in this thread.
hth
regards Runa
2010/6/2 Runa Bhattacharjee runab@redhat.com:
Okta Purnama Rahadian wrote:
why this is not english version ? it�s too hard to translate into indonesia
The default page *is* in English:
http://www.redhat.com/docs/manuals/enterprise/
I used the Spanish page as an example relevant to the conversation in this thread.
In that page "en inglés" means "in English".
It shows my point, you'll see all the available books, whether translated or not, in the localised page.
k.r.
Domingo Becker (es)
translate for Legal Notice in Indonesia Copyright © 2010 Red Hat. Dari teks dan ilustrasi dalam dokumen ini dilisensikan oleh Red Hat di bawah Creative Commons Attribution-Share Alike 3,0 Unported License (CC-BY-SA). Sebuah Penjelasan CC-BY-SA tersedia di http://creativecommons.org/licenses/by-sa/3.0/. Sesuai dengan CC-BY-SA, jika Anda mendistribusikan dokumen ini atau Adaptasi TI, Anda Harus Provida URL untuk versi asli. Red Hat, sebagai pemberi lisensi dokumen ini, menghapuskan hak untuk menegakkan, dan setuju untuk tidak menegaskan, 4d Bagian dari CC-BY-SA untuk sejauh yang diijinkan oleh hukum yang berlaku. Red Hat, Red Hat Enterprise Linux, logo Shadowman, JBoss, MetaMatrix, Fedora, logo Infinity, dan RHCE adalah merek dagang dari Red Hat, Inc., Terdaftar di Amerika Serikat dan Negara-negara lainnya. Linux ® adalah merek dagang terdaftar dari Linus Torvalds di Amerika Serikat dan Negara-negara lainnya. Semua merek dagang lainnya adalah milik dari profil Anda.
1801 Varsity Drive Raleigh, NC 27606-2072 USA Telepon: +1 919 754 3700 Telepon: 888 733 4281 Fax: +1 919 754 3701 Abstrak
Red Hat Enterprise Linux rilis minor, sebuah Agregasi peningkatan Individu, keamanan dan ralat memperbaiki bug. Red Hat Enterprise Linux 5,5 Catatan Rilis dokumen perubahan besar dibuat untuk Operasi 5 Red Hat Enterprise Linux Sistem dan menemani PERUSAHAAN aplikasi kecil untuk rilis ini. catatan rinci semua perubahan kecil dalam rilis ini tersedia dalam Catatan Teknis. Ikhtisar Red Hat Enterprise Linux 5,5 rilis meliputi Hardware Pemberdayaan EX-Boxboro untuk platform Intel, prosesor AMD Magny-Cours dan prosesor IBM Power 7. Virtualisasi adalah Peningkatan, dengan dukungan untuk beberapa 10 SR-IOV kartu GigE, dan penggunaan otomatis hugepages Ketika diaktifkan untuk memori virtual pada sistem tamu.Interoperabilitas Perbaikan mencakup perubahan kepada OpenOffice untuk Microsoft Office 2007 Filter, Samba untuk Windows 7 boot kompatibilitas dan dukungan untuk mesin virtual menggunakan layanan berbasis Microsoft PXE.
On Wed, Jun 2, 2010 at 7:19 PM, Domingo Becker domingobecker@gmail.comwrote:
2010/6/2 Runa Bhattacharjee runab@redhat.com:
Okta Purnama Rahadian wrote:
why this is not english version ? it�s too hard to translate into
indonesia
The default page *is* in English:
http://www.redhat.com/docs/manuals/enterprise/
I used the Spanish page as an example relevant to the conversation in
this thread.
In that page "en inglés" means "in English".
It shows my point, you'll see all the available books, whether translated or not, in the localised page.
k.r.
Domingo Becker (es)
trans mailing list trans@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/trans
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/02/2010 08:19 AM, Domingo Becker wrote:
2010/6/2 Runa Bhattacharjee runab@redhat.com:
Okta Purnama Rahadian wrote:
why this is not english version ? it�s too hard to translate into indonesia
The default page *is* in English:
http://www.redhat.com/docs/manuals/enterprise/
I used the Spanish page as an example relevant to the conversation in this thread.
In that page "en inglés" means "in English".
It shows my point, you'll see all the available books, whether translated or not, in the localised page.
k.r.
Domingo Becker (es)
Looks good to me!
- --Eric
-
Domingo Becker -
Eric Christensen -
Miloš Komarčević -
Okta Purnama Rahadian -
Ruediger Landmann -
Runa Bhattacharjee