From: Russell P. <rph...@as...> - 2006-08-11 15:04:26
|
<SNIP> >That is obviously nicely coordinated through the gettext framework - as >long as we work with a single .po file here, there's hardly any reason >why filenames should "collide". > >As I suggested to Russ though, it may be a good idea to already think >about a naming convention for the filenames of the .po files here - >while the number of translations is still small and thus the effort to >rename the files to match a certain naming convention is not too much. > >To be more constructive in my "criticism" here: I would suggest to name >the .po files using the ISO 639/3166 codes for country and language (one >language may be spoken in different countries with slight variations - >think of US-English as to Britisch English) - something like "en_GB.po" >or "de_DE.po" for example. I'm planning to use a naming scheme like this. However, I want to study gettext some more before I decide on a final scheme. I have an idea that gettext looks for translation files named in this way, in which case this would be ideal. I want to be sure before I commit, though - I don't want to have to change the scheme at some point in the future. >2) Translation of the helpfiles (needs more elbow-grease) > >Here things become a bit trickier - obviously the filenames will collide >with each other if we just translate the contents of files like >"01.html" yet keep the filename and/or location. > >Question here: should it be a "feature" that any newly installed >translation of a helpfile overwrites the current one, or should one >instead be able to choose from a set of languages, perhaps even be >allowed to change the languages in the configuration of Panic Button "on >the fly"? > >In that case I'd think we need a convention for the help file >directories - a combination of language and country code immediately >springs to mind (like "de_DE" and "de_CH" to distinguish between German >German and Swiss German, or "en_GB" and "en_US" for English Englisch and >US English). Obviously the ISO 639/3166 codes would apply: >http://www.gnu.org/software/gettext/manual/html_chapter/gettext_15.html #SEC221 >and >http://www.gnu.org/software/gettext/manual/html_chapter/gettext_16.html #SEC222 >specify those. The help file that is distributed is an MS HTML Help file (currently named "PanicButton.chm"). I think it would be logical to use the same naming scheme that we settle on for the l10n files (eg en_GB.chm). The .html files (like 01.html) are the source files for the .chm file. Putting them into directories named the same way as everything else seems sensible. >3) Translation of the Installer (currently needs some more extra thought) > >The PanicButton.aip file can obviously be found in the CVS: > >http://panicbutton.cvs.sourceforge.net/panicbutton/panicbutton/MSI/Pani cButton.aip?view=3Dlog Actually, that is for the attempted (and now abandoned) MSI installer. It's an XML file, so it could be edited using an XML editor or a text editor, and MS released an open source MSI compiler (http://sourceforge.net/projects/wix/). The current installer is created using Inno Setup (http://www.jrsoftware.org/isinfo.php). As far as I can tell, the licence is not OSI-approved, but it appears to meet all the criteria for an OSI-approved open source licence. >One would require the "Advanced Installer" >(http://www.advancedinstaller.com/) for this part to be revised >according to the language in use - and that's where my "problems" (well >perhaps only: perceived problems) start: this tool only allows to create >an "English speaking Installer" (at least the Freeware version - the >Professional and Enterprise versions come with 15 languages supported), >plus it's requiring anyone participating in the translation process of >Panic Button to actually purchase (as said, the Freeware version is only >available in English) a closed source software in order to take part in >an open source project - which raises at least some of my neck-hairs. I try to use open source as much as possible, and the only closed source software I currently use for Panic Button is Microsoft's HTML Help Workshop (http://tinyurl.com/gle) to compile the .chm file. I use that because .chm is the standard Windows help format these days, and I don't know of any open source software to create .chm files. If anyone knows of an open source .chm compiler, I'll happily switch. I'm not sure how Inno Setup handles translations, but I'm reasonably sure that the setup can be localised, so it's just a matter of working out how ;-) <SNIP> >Currently that exercise looks fairly simple: as far as I can see, >currently the installation stuffs all the files into the usual Windows >programs directory, and creates shortcuts in the Start-menu (a) creating >a folder for PanicButton and b) adding a shortcut to the PanicButton.exe >in the Autostart folder). > >If that's really all there is to it, any installer should do the trick - >what about new file locations for the internationalised version though? I suspect that the l10n files will be in one or more sub-directories, in which case any installer should be able to cope. >What sounds obvious here probably results in a "staged translation" >effort as a consequence: > >a) first translate the .po file (trivial, as I said - poEdit seems to do >a pretty good job in providing a comfortable environment for this) >b) create screenshots of the new user interface, to be used in the helpfile >c) translate the helpfile >d) create an installer - best choice here would obviously be one where >(as a user) you select the installation language and then automatically >end up with an installation of Panic Button in your chosen language. > >Obviously this repeats with each new release as the features of Panic >Button become more - sounds like an ever increasing amount of work just >to manage that, never mind working on Panic Button itself. > >Should we really coordinate that in a centralised spot (e.g. the Panic >Button website that Russ provides) or should we decentralise that effort >and make the maintainer of each translation responsible for the >provision of both the zip file and installer version of PanicButton, >even if this means that not every new version may not immediately be >available in every language of the previous version? The extra work involved in co-ordinating translations is one reason why I wanted to use gettext. Because we use gettext, we have the option of using Rosetta (https://launchpad.net/rosetta) for managing translations if we decide we want to. I don't want users of localised versions to feel that they are "second-class" users, so ideally I'd like all versions to be released simultaneously. I'd also prefer to have one file for all users, with all translations included. If the file sizes get too large, I might have to re-think that, though. I'd suggest that we do it this way: 1. I announce a release date to the translators. The .pot file, help files, and features will not change after this announcement. 2. Translators work on updating their translated versions of files. I use the time for testing, bug fixes, etc. 3. Translators send their completed translations to me. 4. Once the translations are received and testing is over, the new version is released. Russ |