On August 18, 2011 05:12:31 AM cri wrote: > I agree with Vaclav considerations about gettext. I also want to add > that with a gettext infrastructure the updates on webpages text can be > more easily tracked by any translator simply by updating the po file.
And how would such a system deal with incomplete translations? I understand your considerations and motives and support the idea of simplifying life for translators. I would like to see a prototype, or even better: real life examples (if they exist) before making up my mind (for whatever my opinion is worth - if you are determined to do something you will do it). My concern is not about gettext specifically. I have never seen it in action on a website and am open to consider it. My concern is about a viable multi-language platform for a website, something that I have a lot of experience with. I've lived most of my life in multi- lingual countries and I am a polyglott. I participated in different roles to projects that had multi-language websites, some of them of great complexity (on a trading platform each and every word needs to be signed off by a lawyer). I have implemented complete multi-language websites myself. I have seen gettext very successful in the app space but have yet to see it in web space. There are multiple factors and trade-offs at play. When Bruno developed the current Hugin website, he considdered them and this website has served us well. I am not saying that it can not change. I am saying that all of these factors will need to be weighted. You mention yourself that you have little experience. I would recommend small steps. If you make yourself dependent on gettext at this early stage, you risk making all other additions dependent on it. If it turns out not to work, your other additions will go with it as well and this would be sad. > Otherwise you need to keep continuously an eye to the tracker in order > to see what changes have been made to a webpage's text. Plus, with > gettext, there is less possibility to break the html code of the > webpage. As a provoking thought: why translating at all, then? Why not use Google Translator to generate automatic translations? You can be sure that it does not break the html code and that it is abreast of the latest changes, if these are the two most important factors to consider... Frankly: keeping up to date with the tracker is enough for a website like Hugin. This is not a news website changing every hour; and there is no need to keep an eye on the tracker unless you translate bleeding edge not yet released stuff. Frankly again: the occasional break in the html code of a single page is not critical either, especially since it concerns mostly bleeding edge pages not yet released / published. It's called work in progress. I will have some feedback to you about the recent changes you made to the Italian translation of the upcoming 2011.2.0 release. Have not got around to them because yesterday my workstation's HDD decided to quit. The SSD for the netbook is scheduled to arrive today and I hope to restore the backups and be back in full production mode this weekend. > Talking about the header I really want to see photographers credited > by showing their images done with Hugin. So I've already experimented > a newer solution using the already available panos on the hugin-web > repo. The solution consists of a tabbed text file with data about > image, all in a row, like title, author, and a link to a webpage. What > is really needed in that case are all those informations for any pano. Same consideration made here. You're faster than me. Instead of a tabbed text I was using a JOSN file with a client-side JavaScript lookup. Equally easy to edit; does not need server-side parsing (i.e. resource wasting). I've discussed the problem of information collection with Bruno a couple of weeks ago. Many if not most of the banner images up there belongs to him. And he suggested: why not starting from scratch? Would make sense to me. Then we can put up an appropriate process, and make sure that we have complete information for all the images used, including author and proper licensing. An advantage of keeping the website in an SCM is that we would find the history/documentation of this in the SCM itself. I tried to look for authors/credits/licenses in the SCM log, but this happened too long ago and so the information is incomplete. Yuv (heading out to wait for the postman with the SSD before also the HTPC quits on me)
signature.asc
Description: This is a digitally signed message part.
