On September 1, 2011 04:00:36 AM cri wrote: > On Aug 28, 8:58 pm, Yuval Levy <[email protected]> wrote: > > What would it take for Hugin to adopt transifex? > > It's really simple from a translator's point of view. You just need to > create an account and start translating via a web interface. [1]
I looked quickly at transifex. It defines itself [3] as "designed from the ground up for *dynamic*, *frequently-published* content". This is not a description of the Hugin website. Even with 2-3 releases per year and maybe the addition of 2-3 tutorials per year, Hugin is fairly static. > > Of course it does. I would never reccomend using google translate, and > > given the limited set of options: > > 1. English-only > > 2. HTML-translation > > 3. Google-translation > > > > My order of preference would be 2,1,3. > > I'm curious, can I ask why you prefer HTML translation over a gettext > managed one? I'm curious. Where in the above "limited set of options" do you see anything mentioned about gettext compared to HTML translation? That said, I can now confirm that if a getext "managed" translation is what Vaclav checked into the hugin-web repo, I prefer HTML translation over it. > I'm a translator of various projects from almost five > years and I can only see positive aspects in using gettext as > infrastructure and poedit at translation level, over others tools. > Maybe I'm missing something or are just my tastes? ;-) I am fluent in five languages and am familiar with most aspects of translation, including the technical ones. I do see the positive aspects of using gettext/poedit for the translation of applications. I fail to see them for the translation of long texts such as manuals and websites. Specifically for the Hugin website, I prefer HTML translation over a gettext "managed" one because IMHO the unit of translation of a website is a page while the unit of translation of an application is a message and gettext is designed for that: translating messages. The result is that: 1. the gettext translation takes paragraphs out of context 2. the gettext translation of frequently changing sites is likely to result in a horribly desynchronized patchwork of translated and untranslated paragraphs on the same page. I call this the Babel-effect. And I rather have no translation at all; or an outdated translation (with timestamp) than a patchwork translation. 3. an extra layer of complexity is added to the editing process with no apparent benefit. the text and the markup are taken out of context and thus breakage is more likely, not less. > Thanks Yuv for showing me the path! > I've experimented a bit and made some modifications to the banner > behavior and appearance. [2] > > If there are no comments/modifications I can apply the changes in the > nd folder to the main website. not so fast, please. Applying the changes to the main website now will result in a few unintended consequences that require a little bit more thought / coordination. 1. we currently have incomplete data for the entries in the banner, except for the one that you added. you want to discuss/decide what to do with the existing banners. your options are: a - delete them all and start from scratch, asking people for contributions and specifying what you expect from contributors, e.g.: -- 165 pixel high -- tile horizontally -- made with Hugin -- license -- format (JPG, PNG, GIF) and maybe file weight (Kb) -- information (author, title, optional link) b - find out who contributed the existing ones and if they want to complete the information. in the meantime comment them out / exclude them from the production JSON file. (b) is probably not practicable, so (a) is your best choice, in which case you want to first call for the contributions and wait until you have enough of them to ensure a nice rotation before you apply the changes. 2. currently the website rotates one single panorama every hour, and that panorama is shown to every visitor from all over the world. think of it as a "panorama of the hour". this was Bruno's concept for the site. It has the side-benefit of keeping the site fast and low on bandwidth requirements (not loading a new banner every page). Even after your modifications the proof of concept [2] just picks up a random image. your options are: a - replicate the existing behavior, e.g. picking a random entry from the JSON file once per hour and serving that one to every visitor. there are a few ways to implement this. b- decide consciously that you want a different behavior than the current one. in this case you want to consider the consequences of the different behavior. Maybe you come to the conclusion that the slow down is not significant enough. But maybe you want to stay on the safe side and pick one random entry from the JSON file once per visit, remember it in a session cookie. 3. Last but not least: I personally find that the credits in [2] are too big. I would use a smaller font and a more transparent background. But these are my personal preferences, not objections. It's your design, you do what is right. Yuv > [1] https://translations.xfce.org/ > [2] http://hugin.sourceforge.net/nd/bannertest.shtml [3] http://help.transifex.net/user-guide/getting-started.html
signature.asc
Description: This is a digitally signed message part.
