> 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. Phew *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 > anytime. Ahh ok. I misunderstood then. That sounds good. Anyway. I hope this was the kind of feedback you guys were looking for. \Kenneth
_______________________________________________ gnome-i18n mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-i18n
