ciao Cristian, sorry you had to wait so long for my reply - I had not yet recovered from my notebook's HDD crash that my desktop's HDD crashed as well (Murphy's law: the replacement HDD was on the desk for three days). I spent most of my time at the PC in the last two weeks recovering data from partial / incomplete backups and from the disk itself (I can read data from it, albeit slowly and between "tocks", for about 30 minutes at a time after deep-freezing it for two hours).
On August 19, 2011 06:09:26 AM cri wrote: > To cite two: www.gnucash.org and ww.xfce.org (I've translated both of > them to Italian). (look for the languages selectors on the upper- > right) Looks good. Is there a possibility to peek at the back-end? Or to set up a back-end on hugin.sf.net to play with / understand? > No more than a year ago the xfce website was translatable only at the > html level. The developers then decided to switch to gettext and to > use transifex as translations management platform. I am not familiar with transifex. Can you guide a newbie through the system? how would I translate xfce into another language? What would it take for Hugin to adopt transifex? > > 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. > > I'm open to any kind of challange and I'm here to learn something > during the process. > I'm a newby and that's why I want to do the changes in a beta > environment. I'm with you. We are all newbies. > > 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... > > The problem is that sometimes (often) google translate breaks the > translation. 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. The question was to provoke a thought. What if gettext breaks other elements of the website? E.g. personally I rather maintain the website in an SCM like Mercurial than using a CMS like Drupal. Nothing against Drupal (a wonderful CMS), but I find it more efficient to work directly in the HTML with an SCM than using a web-based interface to edit a Drupal site. And so if I were asked to rank between: 1. English-only with SCM editing 2. limited HTML-translation with SCM editing 3. easier/full translation with CMS editing My order of preference would be 2,1,3. See where I am getting at? All the factors need to be weighted. > > 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 don't know JavaScript and I've just scratched php: I'm not in any > way a programmer. I cant' t really discern what's the better solution > about resources, I'm only looking for a working solution given my free > time and knowledge. OK, [0] is for you. Strongly inspired by your [1]. The text data is mostly empty because it would require tracking back and asking previous contributors, but you get the feeling for what it does. Visually it is the same overlay design (although I must say that I find it a bit too big, I did not make any changes to the visuals). In the backend, there is no PHP, so no server-side CPU cycles are used, and it is not dependent on Flickr. The images come all from the existing selection of banners and the text data is in a static JSON file [2]. The only consequences on server resources are that in its current implementation it will generate more traffic, but this is just a proof- of-concept and it can be implemented to mimic exactly the current behavior if that's desired. The current behavior of the Hugin website is that one single image is declared "panorama of the hour" and shown as banner to every visitor on every page. The behavior of [0] is that a random banner image is loaded at every page view. I did it just because it was the simplest solution to prove the concept (one single JavaScript line). Mimicking the current behavior would require a little bit more scripting. Not much, but I don't have time at the moment. You will find everything in the /nd folder of the website, which you are free to peruse for your experiments as well. Modify and play with it as you want. There is also a PHP code in one file there. It generates the static JSON file in a more human-readable / editable way. It's a stub for future expansion. It is thinkable to maintain/complete that file; or to use it to parse a directory, a text file, or a database input. The key is to generate the JSON file only once (every time there is an update in the banners) and to use the static JSON file to serve the site. I hope it helps you see the difference between PHP and JavaScript, and maybe entices you to push the envelope a little bit, the same way you enticed me to push the envelope in terms of visuals. Remember: the most important is the way, not the goal. If you make new learnings and new friends along the way, it will be a success. I look forward to see what you'll do with this. Yuv [0] http://hugin.sourceforge.net/nd/bannertest.shtml [1] http://www.crimodels.webatu.com/phpFlickr-3.1/hugin-bg.phtml [2] http://hugin.sourceforge.net/nd/banners.json
signature.asc
Description: This is a digitally signed message part.
