On Saturday 28 August 2010 19:30:45 Ron Guerin wrote: > Chris Knadle wrote:
... > > My girlfriend Criss uses this URL shortener, which she seems happy with. > > It's in PHP and uses MySQL for the DB backend. > > > > http://yourls.org/ > > > > At the moment I don't think there's any URL shortener within Debian > > AFAIK. > > I'm trying to re-write mine to be less horrible code and to take into > account some reasonable feature requests I've gotten, like translation > files. I'd be honored if it somehow got into Debian after that, > although I thought they had higher standards than anything I produce. As far as I know (disclaimer: I *do not* have direct experience in this area), there are basically three things to consider when trying to get a project uploaded to distributions: A) marking a particular version of the software as "stable" [important] B) software code portability for other architectures C) support for localization [i.e. l10n written language translation] A) is most important, as Debian packagers typically will only package software versions that are marked as "stable". This is the part that can annoy software authors, as it means what is packaged might be somewhat old. From the package management point of view, the packager wants to know that the software has been tested and works, i.e. "stable". After the software is packaged it is then first uploaded to Debian Sid, also known as "Debian Unstable". So ironically this generally means that only "stable" software gets uploaded to "Unstable". B) can be important as distributions support many architectures -- and it would be nice if the software produced would, say, work on an ARM-based laptop or mobile device. In practice what happens is an auto-builder daemon is used on the software package, and if the package fails to build for a particular architecture then the software simply isn't made available for that architecture. C) is important because distributions support a lot of written languages. UTF-8 unicode support is important too, as it's the default LOCALE upon installation at least for Debian. A friend of mine using a Mac recently had trouble with this concerning the 'tr' command to translate carriage-returns to line-feed characters. He did the following, which was very logical and should have worked: $ cat funky_lines.csv | tr '\r' '\n' > fixed_lines.csv However the file he was modifying contained UTF-8 characters, and the 'รถ' characters [that's an 'o' with two dots above it] cause the 'tr' command on OS X to die with an error of 'illegal character' because it apparently isn't UTF-8 aware. Oops. [The 'tr' command on Debian /is/ UTF-8 aware, BTW.] Obviously you cannot do the written language translation yourself to all of the languages that a distribution might support -- it's just important to put in /support/ for translations so that someone else can translate the strings. I've dealt with translations in Qt using the 'tr' macro wrapper around strings, but I'm not sure how localization is typically handled in, say, C/C++, bash, Python, etc in an architecture-generic way. -- Chris -- Chris Knadle [email protected] _______________________________________________ Mid-Hudson Valley Linux Users Group http://mhvlug.org http://mhvlug.org/cgi-bin/mailman/listinfo/mhvlug Upcoming Meetings (6pm - 8pm) MHVLS Auditorium Sep 1 - BOINC Oct 6 - Creating Firefox Extensions Nov 3 - Bug Labs
