Posted by Diego "Flameeyes" Pettenò
Mon, 31 Dec 2007 20:22:00 GMT
Dear lazyweb, this time I am asking for opinions and comments, rather than writing my own :)
Today I’ve been trying to clean up my home office, and I seen how many reference books I have that I could have downloaded, or at least bought, in PDF format, rather than printed or bought in solid paper form. While I’m quite a bookworm and would probably continue buying novels in solid paper form, I’m considering an electronic paper device for technical references (which are also those who take more space in my library at the moment).
I was suggested more than once the Sony Reader.. while I don’t really find myself a Sony fan, I can see they are quite advanced in what they do, and being able to read standard PDFs should be good enough to me, as I just need it for reference manuals (for now). I also seen there is a project already to get the reader to work on Linux, and it seems well developed, so I’m trusting I would get it to work on Linux quite easily.
But as I like first-hand impressions, does anybody have any comment to give me about this?
Posted in English | Tags Comments, Lazyweb, libprs500, Reader, Sony | 4 comments
Posted by Diego "Flameeyes" Pettenò
Sun, 30 Dec 2007 14:34:00 GMT
Today’s plans of working were messed up, as I’m waiting for a friend of mine in about an hour, so I dedicated the first half of the afternoon at fixing up the repositories for ruby-hunspell and rust, as I wrote yesterday.
I also ended up adding a few more projects of mine to Ohloh as it helps me tracking down of stuff I’ve been doing and I left behind.
Then talking with a friend of mine (hi Alberto), I remembered that there were USE flags in xine-lib that are non obvious, and I shold have document them already. I asked drac for permission, and now xine-lib’s metadata.xml has documentation for real, win32codecs, mad, flac, gtk, imagemagick, gnome, mmap and truetype USE flags. It should cover all the non-obvious ones.
Checking xine-ui too, after fixing one of the bugs that were reported to xine’s bug tracker after I closed them on Gentoo’s bugzilla as UPSTREAM, I also found that there was a very old copy of xine-ui still hanging around in portage. Thanks to drac, that’s gone, as well as the ncurses USE flag on xine-ui that was unused anyway (now the code in configure is gone from CVS too). And if you use xine-ui from CVS you’ll now get a datafile for shared-mime-info for tox playlist files, thanks to Peter Fox.
I also took care of updating the xine’s maintainer guide removing some outdated and now pointless information, and providing the tracker as main submission entrypoint, rather than xine-devel. There was a lot of stuff to update, as the guide was not updated for exactly 11 months (last change being 30 January, before I left from Gentoo).
Now I’m mostly tempted to document a few more things on xine-ui’s flags, and add some IUSE defaults to xine-lib so that users gets some sane defaults (like enabling a52, dts and mad decoders, and disabling mmap and truetype).
So basically today is a day of migrating documentation so that it follows the current ebuilds, and adding proper flag documentation to metadata rather than relegating it around the maintainer’s guides, at least user side. Expect more commits from me just to add documentation :)
Posted in Gentoo, English | Tags Bugzilla, Documentation, Guides, Metadata, Trackers, USE, xine, xineui | 3 comments
Posted by Diego "Flameeyes" Pettenò
Sun, 30 Dec 2007 02:31:00 GMT
As you can easily imagine from what I wrote the past few days, I’ve been busy trying to cleanup after myself in old projects that are near to abandoned. I wrote about my resolution to spend more time working starting new year, to save some money for getting my driving license and a car, and in the past days I cleaned up both the rbot bugzilla plugin (as well as rbot’s ebuild) and then nxhtml today, so it was quite obvious that I had also to take a look to long ignored projects like ruby-hunspell and rust (and of course rubytag++).
I started with ruby-hunspell as with that I can also fix the hunspell plugin for rbot (and thus put back in the only feature left over from ServoFlame). The first problem I wanted to tackle down was to remove the cmake dependency. As I said yesterday, I’ve started feeling the power in GNU make, and I also have enough reasons not to use cmake that if I could convert the build of the extensions (they are quite simple after all) to simple GNU make, I would do it gladly.
Indeed switching the build system to simple GNU make with some tricks around was not difficult at all, and the result is good enough to me. It’s not (yet) perfect, but it’s nicer. I also hope to generalise it a bit so that I can reuse it for rubytag++ too, and hide some of the dirty tricks I use.
Thankfully there is a good note about it, in the five releases between the previous time I worked on ruby-hunspell and today (1.1.4 then, 1.1.9 today), hunspell added support for pkg-config files, making the build system quite nicer. Also thanks to git improvements, making the tarball is quite easier. And thanks to the power of GNU make, instead of having a tarball.sh script, it’s now simply make tarball (although I will probably switch to make dist, I thought about this just now).
The problems weren’t laying too far though. First, I changed something on rust some time ago it seems, and now the ruby to C type function changed name, so I had to update the ruby-hunspell description script to suit that change. Then there is the problem that Hunspell now hides some of the functions being experimental (and by the way do they have any consideration for the object ABI? Dropping some functions on a preprocessor conditionals inside a C++ class isn’t the most sound of the ideas, I’m afraid…), so I had to comment those. The biggest problem came with the parsers extension, that used to provide bindings for the libparsers library installed by hunspell.
The libparsers library is not installed only in static form, and its headers are not installed at all. This is probably half intentional, as in they probably consider the libparsers library an internal library that other projects shouldn’t use, so they removed the header files, the problem is that they still install the library at this point, making its possible use a bit ambiguous. At any rate, for now I disabled the parsers extension, it wasn’t very much hunspell related anyway, so I will certainly prefer if they dropped it from being installed entirely. That extension was also the only one that had a testunit, I should write a testsuite for ruby-hunspell and the hunspell extension too, so that at least I have something to test with.
There is one big problem though, to release a new ruby-hunspell, which is a requirement for rbot-hunspell, I need to do a release of rust, too, but I don’t remember much of rust details, it has been almost an year since I last worked on it :( Additionally, my /tmp is noexec now, it wasn’t when I prepared the testsuite, so the tests fail as the shared object built in /tmp can’t be loaded in memory. I’ll have to test tomorrow if TMPDIR environment variable is respected, in which case I’d be using /var/tmp. I’ll also add a make dist target to rust so that I don’t need extra stuff to prepare the packages.
Finally, there is the problem of the git repositories: for some reason pushing to the remote repository accessed through this trick fails like there was nothing to push. Considering I now have my own (v)server, I’ll probably just move rust and ruby-hunspell back together with the other git repositories I export. This will also simplify thins when I’ll put gitarella back too.
Tomorrow will be dedicated to work for most of the time, but if I can squeeze some time for this I’ll try to address the issues, and I promise this time I’ll write more comments and documentation.
Posted in English | Tags Extensions, git, GNU, Hunspell, Make, Ruby, Rubyforge, RubyHunspell, Rust | no comments
Posted by Diego "Flameeyes" Pettenò
Sun, 30 Dec 2007 00:25:00 GMT
So the new year is near, and this time I want to make some resolutions I’ll try to live up to.
The first is to start detaching from things, from objects. I have one big problem, I have difficulty detaching from objects because they remind me of something, even when the things are completely useless and just take up my space (and I don’t have much space). I attach myself too much even to shipment cardboard boxes for stuff I received or bought, and this becomes a problem on the long run. I also have to keep most boxes of the stuff I buy because of the warranty requiring me to keep the original boxes for at least two years (more if the warranty is extended).
I already tried putting an old soundcard on eBay, but the result was unsuccessful (not even a single offer), now I tried an old motherboard, who knows, maybe I can get rid of some stuff, and “stash away” some money. Unfortunately most of what I have here is probably crap for the average ebay user, so I doubt it would end up sold… I have a few old keyboards, some old video cards, and stuff like that. I’ll try to see if I can make something out of them, otherwise will probably either throw them away or put them up available for free for anybody (beside shipping costs).
The second resolution is the most important one, this year I have to take my driving license, and a car. I can’t be stuck in the nothingness where I live forever, I need a car, and I need to get a daily job, at least temporarily, to pay the car. I’m lucky with this, I have an electronic shop at ten minutes from my house (by car) and I know they change personell quite often, with some luck I should be able to push myself to do six months were just to pay for the car.
I’m finishing what I had left floating around me in Gentoo in the next few days so I can spend more time on working during the new year, as I really need to get some money saved, even if after my hospitalisation that is difficult. Trying to get away from 2007, I also spent basically all the money I have, buying stuff for me and gifts for my friends, this way I can start anew with the new year.
On a Gentooish note, today I created three new packages, one in the main tree and two in my overlay. The first is libasyncns by Lennart, I always put it back into my TODO list to add one day as it’s an optional dependency for PulseAudio; the arch teams now hate me because I’m asking them to re-keyword PulseAudio once again… Lennart you always use bleeding edge stuff, don’t you? :) First it was libatomic_ops (which I had to add to portage), then PolicyKit (which luckily enough steev added to portage about at the same time as I needed it), and now asyncns, which was there from the start, but I skipped up to now :P
The other two packages are Emacs modes; I updated nxhtml-mode (this time a different Lennart ;) ), now it actually works fine for me even on Gentoo, with indentation not throwing up annoying messages to me anymore. But it has a new dependency, app-emacs/cgi+ (new package), which in turn depends on app-emacs/cgi (also new) and app-emacs/httpd. Certainly nxhtml-mode is not one of the most self-contained packages in Gentoo (actually it’s completely self-contained if you download and install it manually, but as usual in Gentoo we prefer using separate packages if they are available).
And nxhtml-mode actually spawned its share of new packages as dependencies, which is not entirely bad as it allows Gentoo’s Emacs support to improve :D
Posted in Gentoo, English | Tags CGI, eBay, Ebuilds, emacs, libasyncns, NewYear, nXhtml, PulseAudio, Resolutions | 2 comments
Posted by Diego "Flameeyes" Pettenò
Sat, 29 Dec 2007 03:11:00 GMT
After Harald’s entry about the Oxygen cursors, I wanted to give them a try too.
As the author is our very much Italian ruphy, I asked him about them directly :) And with some sinergy, there are now very interesting news for all you Gentoo users who want to try the cursors :)
First of all, I’ve added a live Git ebuild to my overlay for the oxygen cursors. As it’s a live Git ebuild, the cursors are generated when installing from it, this means that it takes some time to have them available, and also that it requires xcursorgen and InkScape (to do the SVG -> PNG rendering). Easily enough, the released copies will be distributed in pre-compiled tarballs, so there will be no dependency over either of them.
While looking at ruphy’s build scripts to build the cursor, I actually thought it would have been nicer to have them using a makefile, so that it would make proper use of dualcore systems (by using more than one job), and it would also make it easier to prepare the ebuild. So I took some time and.. rewrote the whole build system to use Makefiles instead. Thanks to Riccardo, the makefiles are now in the upstream repository, and the ebuild I committed was quite simplified from the one I wrote initially.
The nice thing about make is that you don’t use it only for C/C++ compiled code, you can use it to actually “make” almost anything. I use it for the nxml Gentoo schemas to download the schemas and clean up after itself too. Unfortunately knowing all the possible uses of GNU make is a bit difficult, I suppose I could read about it in the info pages, but as I hate reading a lot on the screen (and I don’t have any eInk-based reader yet – I’m waiting for something with the usability of Amazon’s Kindle and the openness of… nothing actually available), I just added this book to my wishlist… if anybody would like to help me help free software ;)
Anyway, I really do like the new Oxygen cursors, especially the black ones :) Thanks ruphy and the whole Oxygen team!
Posted in Gentoo, English | Tags Ebuilds, git, KDE, Make, Oxygen | 3 comments
Posted by Diego "Flameeyes" Pettenò
Sat, 29 Dec 2007 02:12:00 GMT
Yes, I know I’m boring when I start talking for a few days one after the other about a given topic. At the moment I’m boring with rbot, on which I worked a bit today too.
First of all, the news is that no more dependencies are needed or added to the ebuild, good. I also fixed the time plugin so that it’s disabled if timezone USE is not present. This should let the build stay quiet for a while.
Then I cleaned up the bugzilla plugin a bit, re-enabled it in ServoFlame, added the xine bugtracker and… prepared to release it.
I started versioning it on git ( git://git.flameeyes.eu/rbot-bugzilla.git ), and I put a tarball on my site so that it’s more easily found. I also changed the license, it was MIT, but it’s now Affero GPL 3.
Why Affero? Well, plugins for a bot is something you often end up editing to improve; by forcing users to actually make available their changes it should make it more easy to improve the code on the long run. Also, I find it interesting to see if actually it would be used and the license properly applied (note that the easiest way would be to send the patches upstream so I actually make the modified plugin available to anyone).
If there is request, I’ll probably put back the old MIT-licensed version; actually at the moment even ServoFlame is using that, or rather a modified version of that, rather than the AGPL3 version (which is more advanced); this is because of the other thing I’ve done after preparing a tarball of the plugin: I wrote an ebuild for it.
So if you have my overlay, just emerging net-irc/rbot-bugzilla will give you a rbot with my bugzilla plugin enabled, the httpclient package installed (as it’s a dependency), and the default configuration already with the bugzillas ServoFlame access.
For now the ebuild is in my overlay, I’m still debating with myself if I should add it to portage (and then actually use portage to maintain the bugzilla plugin used by ServoFlame, too), or wait.
Posted in Gentoo, English | Tags Affero, Bugzilla, Ebuilds, rbot, Ruby, ServoFlame | no comments
Posted by Diego "Flameeyes" Pettenò
Fri, 28 Dec 2007 01:47:00 GMT
Bugzilla always gave me the idea of something slow, heavy, and an absolute waste of resources.
I start to think better of it. While certainly it will kill easily a server when used with big projects like Gentoo or KDE, it seems to be quite decent for a small project like xine on a small vserver.
The other reason why I thought badly of Bugzilla was the amount of perl modules one had to install to get it to work; luckily this problem is gone thanks to Portage, that takes care of everything for me (or almost everything).
The final reason why I thought Bugzilla was not feasible is the interface. God knows the default interface of Bugzilla is horrible. it’s strange considering the the developers are Mozilla related, and it’s also strange that it uses so many tables around for the same reason. I thought tables for non-tabular data were quite out of standard nowadays, I don’t even use them myself when I’m paid to make a site!
Anyway, the template engine used by Bugzilla is quite impressive, and it can be used to actually get Bugzilla a decent interface. There are also some new skins available around that gives it a very interesting effect, although I haven’t used any of those yet. For now I stopped at cleaning up the interface a bit, removing the redundant actions listed at the bottom (they are the same as listed at the top), moving the logout action to the right of the screen like in other webapps, and so the search box.
I also removed a lot of information and links on the index, mostly redundant stuff or stuff like the infamous sidebar, that I never seen anyone using. It’s lot as clean as GNOME’s bugzilla, nor as shiny, but it’s not bad either. I hope to actually improve it in the future too. What I’d really like is to show the most recent reported bugs on the homepage, so that users would see more easily what might be their problem (if it’s a problem that came up recently like the infamous build failure of the internal libcdio copy with the new linux-headers).
Anyway tonight I switched the xine bug tracker to Bugzilla, importing by hand the open bugs from Flyspray (tomorrow I’ll import the closed ones too). I’d like to make the interface more shiny with some icons, but I don’t know which icons would look good with the icy look of the current skin (which is derived from the xine logo and the xine site).
I hope that mailing works, it’s the first time I set up procmail, and I’m not sure if it works properly because I see some errors in the mail queue, connection failures to the mail relay (which is internal to the farm where the vserver is located). Tomorrow I’ll see if it’s easier to just get it to send the mails directly.
If you read about my problem of having data filtered so that the password change requests don’t leak on the mailing list, the solution was quite easy, with procmail and a xine-project user (which is where flyspray was installed, so it existed already).
Also, thanks to the fact that bugzilla is, well, bugzilla, now ServoFlame on Freenode will answer to requests about the xine’s tracker too.
Talking about ServoFlame, today I also worked a bit on its bugzilla plugin, now it uses httpclient, rather than http-access2 (httpclient is the new name of http-access2; I also asked for marking httpclient stable today), and reuses the client instances for the same bugzilla, I haven’t checked if that means that it uses permanent connections yet, but I’d sincerely hope so, as that should improve multiple requests to the same bugzilla, especially for those trckers using SSL (like FreeDesktop). You may now use ServoFlame in all the channels where it’s present to request bugs about the listed projects, to know the listed projects, just ask him to “zilla list”. I finally implemented proper authorization support so that zilla list is available to anybody, but just I can add or remove trackers to the list.
For what concerns the generic rbot live ebuild (which stays where it is because upstream is now suggesting not to use rbot 0.9.10, the last release), I added an nls USE flag the other day, but now I force ruby-gettext on everybody; this is mostly because I want the gem to be generated as much as possible identical to the one that’s going to be released, which means that the locale files needs to be there; anyway it’s not a runtime dependency, you only need to install it to install rbot then it can go.
I also added a dict USE flag; this flag controls the dictclient plugin, a client for the RFC 2229 protocol (that is, dict), that uses the ruby-dict extension. As it needs the dependency or it fails to load, leaving it enabled by default wasn’t really a good idea in my opinion; now if the USE flag is disabled, the plugin is also disabled (by default, you might enable it manually, but then rebuilding with the USE flag enabled takes less hassle); as ruby-dict was not in portage, I added it, this makes it the third package added to portage just to get rbot plugins working (the other two were dev-ruby/tzinfo, for the time plugin, and dev-ruby/shorten for the shorturl plugin).
Unfortunately i already have disabled almost all the rbot’s plugin on my ServoFlame so I don’t see the failure to load most of the plugins when the extensions they need are not found. Tomorrow I’ll see to get an install of rbot on my workstation and with all the plugins enabled I’ll see what does not run correctly.
Okay now it’s very much late, and I should be sleeping already….
Posted in Gentoo, English | Tags Bugs, Bugzilla, IRC, rbot, Ruby, ServoFlame, Tracker, xine | 1 comment
Posted by Diego "Flameeyes" Pettenò
Wed, 26 Dec 2007 00:37:00 GMT
You might remember, or not, that I spent most of November deciding and working on putting online a new bug tracker for the xine project.
This was due to my (and not just my) dislike of the SourceForge bug and feature request tracker, and to the fact that Siggi, the current maintainer of xinehw.de, is not always around to fix stuff on the spot.
Today, when I checked the traker for a new bug was reported, I seen there was announcement of a new version. So I tried to put that online, and to my dismay, the new version fails to work with PostgreSQL in a lot of places. On the bug linked in the download page, the author (I suppose) says that he’s not proactively working on the PostgreSQl support, and that any further bug will have to be fixed by the community.
As I don’t want a bug tracker I have to maintain codebase-wise, too, I decided to give up on using FlySpray. The alternative would be to use MySQL for FlySpray, but as the bug tracker shares the virtual server with this blog, and this blog uses PostgreSQL, I’d rather avoid trying to run two different DBMS on it.
So while I was open to alternative, Lua suggested me to try Bugzilla; he said that the recent versions are easier to set up, and he’s certainly right when he says that the amount of traffic that Gentoo’s bugzilla gets is tenfold times what xine’s ever will (considering that there are just a few bugs reported in the one month that the new tracker has been up, one being my own.
Since version 2.20 (current is 3), Bugzilla supports PostgreSQL properly; considering Bugzilla is backed by the Mozilla Foundation, and that they do provide commercial support for those who are willing to pay, this means that pgsql support most likely will be there for as long as I need, rather than just for a couple of versions before breaking.
Also, Perl CGI is probably faster than PHP, considering that Flyspray is the only PHP thing that runs on the server. Too bad that bugzilla does not provide a FastCGI interface or that would have been probably nicer too.
All in all, Bugzilla does have quite some good points to his favor: it’s a widely used application, well tested, and well known by many users; it’s being developed since years, and it’s probably going to continue being developed for the years to come; it comes in a nice ebuild with all the Perl dependencies satisfied, which makes it quite easier to handle, one of the biggest pain in the ass for Bugzilla is to install and maintain all the Perl dependency packages, thanks to Gentoo it’s gone. Also, Bugzilla is well supported by external software (Malone for Ubuntu, a lot of non-web reporter applications, IRC bots, included my own ServoFlame), and version 3 also seems to have some kind of Web Service interface, which I will probably dig into.
Sure there are things in Bugzilla that I find a big awkward: the HTML interface is so strangely ‘90s, considering it has a browser project behind. Flyspray on the other hand had a nicer look; while I didn’t like the line that appears at the bottom when you apply the changes, with the common smily emoticon which makes it so much forumsy. FlySpray’s home page, with the list of open bugs is certainly more useful than the default Bugzilla homepage, and while certainly Bugzilla’s interface not using a lot of JavaScript is more accessible, FlySpray has a more userfriendly one.
So I prepared the binpkgs (for what they do matter, as most of those were perl stuff), for bugzilla and dependencies, uploaded it to the server, and installed it. It’s currently setup on a shadow vhost; tomorrow I’ll see to make it appear more decent, by putting the xine logo above, changing the colour scheme around so that it uses xine’s colors and so on. If I’m able to do that, it wouldn’t look as ‘90s as it looks now.
There are a few points I still have to clear; to begin with I would like to send a mail of all new bugs and comments and changes to the xine-bugs mailing list as the SourceForge trackers did.
Then there is another problem: Bugzilla requires an account to get the new bugs assigned to for the various components. This is the kind of account bug wranglers in Gentoo have. As it is, we need a default account used by the developers to get the new bugs listed; using xine-bugs would work, if it wasn’t that I don’t really want whoever comes around to just get a new password for the account and do whatever they want with the bugs.
Unfortunately, the registrar used for xine-project.org (Register4Less) does not seem to allow an alias for multiple addresses, which makes it impossible to use a multiple alias as are used on Gentoo. I suppose the easy way around this is to actually set up a full-fledged server on xine-project.org, to receive the mail and handle aliases, then add a procmail rule so that all the mail received by, for instance, xine-bugs at the server is redirected to the xine-bugs mailing list on SourceForge, with the exception of Bugzilla registration and password handling, which would go to the postmaster (that is me at the moment).
I suppose I should start bothering a bit our dear Robin and Ned, in the next days ;) From Ned I’d like to know how the new bugs report on channels is implemented to see if I can add something more to ServoFlame.
So in the next days you might see me spending less time on xine to fix ServoFlame’s bugzilla plugin, and implement a couple other things. And of course I’ll be playing Command & Conquer 3, which I skipped over the last two days because of family stuff.
Posted in English | Tags Bugzilla, Flyspray, xine | 2 comments
Posted by Diego "Flameeyes" Pettenò
Mon, 24 Dec 2007 00:38:00 GMT
Next month KDE 4.0 is going to be released; before that can happen, we need to release xine-lib-1.1.9 which contains some fixes that Matthias Kretz (the Phonon maintainer) added to improve the support for the xine engine.
This time, as the release is actually scheduled to happen in a short timeframe, I want to try something different: I’m calling for translators.
xine-lib, like many other projects, uses gettext to make it possible to internationalize the strings with user-directed message and information. At the moment there isn’t a real translation team, different contributors tend to update the messages from time to time, but many languages are quite behind with the current set of strings that xine provides.
I usually take care of Italian translation, so I’ll probably try to update that tomorrow, and anyway before the release is done. If you’re good at translating from English to your native language, please either look at the gettext manual (if you don’t know how gettext works) or just checkout a copy of xine-lib from the repository (you want xine-lib/xine-lib repository), and start translating.
Either send the patches on the xine-devel mailing list (see on SourceForge, or use GMane), or open a bug on the xine tracker with the translation patch as attachment.
The output of “hg export” of a local commit is preferred so that your name and email is properly listed on the log.
Thanks in advance from me and the rest of the xine project team.
Posted in English | Tags CFT, i18n, xine | no comments
Posted by Diego "Flameeyes" Pettenò
Mon, 24 Dec 2007 00:10:00 GMT
Many might not remember this, because I haven’ t blogged on that topic in quite a long time, but one of my interests is also localization of software. This mainly springs from the fact that I saw and I continue seeing people who don’ t even want to use Linux because they don’ t know English nor they are willing to learn it just for that.
For instance, I wrote before a proposal for “internationalizing ebuilds:”http://blog.flameeyes.eu/articles/2007/02/26/translating-ebuilds-a-proof-of-concept, early this year. I also tried coming up with a feasible way to internationalize init scripts without having to deal with different scripts per every language possible.
With my interest in internationalization and localization, I also started following a Microsoft employee blog, Sorting It All Out by Michael S. Kaplan. A very interesting blog that deals with international issues like language support, Unicode and keyboards. Even if it’s of course mostly centred upon Microsoft products, it’s still an enlightening reading for Free Software developers, as it tends to explain the reasons for some choices made in Windows for properly support internationalization.
Also, the blog is quite interesting because it really takes a critic eye on the problems, showing even what Microsoft did wrong, and those are errors that other developers should really learn from. He also is a Mac user, beside the obvious Windows user, so he sometimes compare Apple and Microsoft products, giving an objective look at the implementations. So it’s really a suggested reading for any of my readers also interested in internationalization and localization problems.
Anyway, today I read his entry about redundant messages, and I was sure: Free Software developers should really learn to check out technology blogs even when they are from “the other side”.
That’s really a common mistake for free software too, using way too many strings to convey the same message. This makes translation quite more difficult, sometimes very difficult, and they might as well confuse users pretty badly.
The same applies to non-identical messages, and I’m actually seeing this in xine right now. The description of plugins is internationalized, but the problem is that even similar plugins use very different descriptions, This means that fuzzy translations can’t really help with translating new plugins.
So for 1.2 one of the entries in my personal TODO list (which I should remember to write on xine’s actual TODO). is to design and document a proper description scheme to be followed by the description of the plugins, this way the description would follow the same scheme, wouldn’t throw off the user with very different messages, and will make translation quite easier.
Kaplan announced that today’s post will be the first of a long series; I will certainly follow it so that I can learn from it and make it easier to localize xine.. then I’ll be hoping that more people will join the xine project to update the translations. On this note, I’ll also write a new entry to call for translators.
Posted in English | Tags Blogs, i18n, Microsoft, xine | no comments
