Re: New GNOME Website - Translation
- From: Kenneth Nielsen <k nielsen81 gmail com>
- To: Lucas Rocha <lucasr gnome org>, GNOME i18n list <gnome-i18n gnome org>
- Cc: jens bluedynamics com
- Subject: Re: New GNOME Website - Translation
- Date: Mon, 15 Jun 2009 11:35:45 +0200
Hallo Lucas and Jens
I have had a look at the proposal. From what I can see it looks fine. What matters to us is that we can maintain the same workflows (fetch, translate, proofread, corrections, upload) that we usually use. From how I understand the proposal it will ultimately become possible to use po-files for everything, so in that case it's all flowers and sunshine.
I do however have a couple of questions.
The default process to create translated content works this way:
1. Create an item and select its language, save it. Its the so called canonical item.
2. Select the language for translation in the content menu. A copy is created and a side-by-side view shows the new items form on the left and the canonical items content on the right.
This need to be repeated for every language needed.
I don't quite understand this. Does that mean that there will be some sort of a webinterface for doing translations of the content as well. If so that opens a whole new can of worms, but I'll let you answer the original questions first, the we can deal with the worms if it is relevant.
However, we're unsure how graphics/pictures are translated.
One possibility for handling localised graphics/pictures is the one currently used for the software documentation. It has the obvious advantage that we (translators) know it. So what happens is that in a "po" folder there is a subfolder "C" that contains the orginals, the english files, within that is another subfolder "figures" that contain the figures used in the documentation. So what we do to localise them is that under the po folder we create a subfolder for our language "da" and under that we create a similar subfolder called "figure" and then we simply place localised graphics/pictures in that folder with names identical to the originals, and then they will automaticalle get used.
Since this structure is already used with xml2po I guess it would be easy to extend.
The "untranslated marker" is removed as soon as one translation is
pushed. If someone changes the English item the translated item isn't
overwritten anymore. They may get out of sync until translation team
uploads the updated translation again.
Is that an established policy for the GNOME website? I'm only asking because I am coruous, not necessarily because I disagree. You should just know that for software and help pages they both revert to the english string if the english string is updated and the translation not yet updated, so the policy is that accuracy in the strings take priority over having the localised. Now I know it makes sense for software and documentation, but I'm not so sure for a website, someone needs to think about this, if they haven't already.
My guess would actually be that it would be better to adopt this policy for the website as well. I can see that if translators are only a small commit, or a few months late in commiting an updated translation, then it makes sense to keep the translated string even if it is slightly outdated. But the reality of the translation world is the often enough it will take more time. Translating the GNOME website, even though I think it is important, will not be first (or even second) on our/my prioritised list as compared to software and documentation, and that means that as soon as we run low on resouces it will be one of the first ting to suffer. Also there is the possibility that some newly started laguages simply give up. In between these two options we may be looking at seriously outdated massages. I don't think it is fair to ask the users to figure that out on their own, and go to the english site for a newer version. Therfore, bottom line, I think that updated english messages should overwrite outdated translated ones.
Regards Kenneth Nielsen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]