Hi Kenneth,
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.)
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. 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.
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.
The marker is a technical detail inside plone and will asure that
the non englisch content (say french) is synced completely with the
original englisch automatically if someone edits the original.
From the moment that content receives a translation from the translation
team, plone will not automatically sync the french content anymore if the
original is changed. That will be the responsibility of the script that
pull the original out of Plone and pushes it into the git repository
(vice versa).
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
anytime.
..Carsten
_______________________________________________
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n