Re: New GNOME Website - Translation

Hi Kenneth,

Hallo Carsten

Before we go any further I should say that I am ONLY a translator, so all my previous comments was only from the perspective of a translator. I know very little about programming and all the other stuff that is used for this.

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.

Yup (except we still need someone to write the glue code between Plone and
the translation repositories (fetch, store, collect translations,
push back to plone) and work out the details of the external api.)

Oh yeah of course. But it is the plan as I read it, that's all I care about.

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.

It's the interface that the default i18n implementation for Plone
(LinguaPlone) offers. We will add an interface that can be used to fetch
the orignal and upload translations (as xml). The web interface should not be
used by translators.

*Whipes cold sweat of his forehead*
We can decide later what to do with the web interface,
e.g. block it or keep it for special tasks

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 speciality with Plone is that a file is not only a file. It's a file with
additionally (Meta)data used in the webpage (Title, Description, Tags, ...)
The glue code between plone and the translation repositories has to deal with
the storage part.

Yes. But I don't see how that makes it more difficult. Put metadata in the po-file along with the rest of the document and the figure file in a folder with a unique (and non-localised) name. Then when fetching translations, get the translations from the po-file, check if the localised figure exist in a certain folder, if it does, use it, and if it does not, use the english one.

Anyhow, as I said earlier, I don't know enough enough about the specifics of how this would be implemented to say whether it can be done or not. Let my simply say, from my pow it would be preferable to use the same structure as for the documentations figures.

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.

I guess it's not even possible to use outdated translations if the original
changed cause the msgid changed (to the updated englisch text) and this new
msgid is not translation. You can't fuzzy guess if there's an old
translated string that could fit.

This leaves either mix up-to-date translations with untranslated strings
(like in documentation currently) or fall back to an all english page if a
PO file is not translated completly. This policy has to be implemented in
the script that pushes the translations into Plone and can be changed

Ahh ok. I misunderstood then. That sounds good.

Anyway. I hope this was the kind of feedback you guys were looking for.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]