On Saturday 28 August 2010 22:05:29 Ron Guerin wrote: > Chris Knadle wrote:
... > > 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". > > This may be an issue. The code I run and distribute now has been marked > "alpha" for about six years now. lol I'm primarily though maintaining > this branch of what is production code and hoping to move forward with a > cleaner, faster re-writing. ([*] I know Joel says this is bad, but I > doubt Joel was thinking about hack hobbyists) In this case what I would do would be to 1) make a .tar.gz of what you've had running for the past six years, 2) mark it as "stable", and /then/ 3) start the rewrite. I don't see anything wrong with rewriting code. I find I do that myself, and many other projects do it too for lots of reasons. And besides, if you're using a revision control system, anything done can also be undone. This is the nice thing about revision control -- it takes away all the RISK of doing a rewrite or adding a new feature which may or may not work out, because the rewrite or the new feature can be developed in a branch and merged later when it's ready. > > 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. > > I am fortunate in this regard to be distributing > architecture-independent code. That's fortunate, and it also makes it far easier to package since it's already platform-inspecific -- the architecture is simply "all". > > 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.] > > My recollection is PHP is not particularly good at handling UTF-8. But > that said, all other PHP scripts in Debian will have the same > limitations I do. At least some PHP programs can deal with UTF-8 strings. Squirrelmail, for instance, is a webmail client written in PHP and has locale support for other languages. > > 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. > > Several of my users (I mean the people who install my code), have > requested translation support and offered translations, and it's the > most requested thing after the API, so I'm planning on supporting > translations at least. > > > 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. > > This is how I'm handling it: > http://www.gnu.org/software/gettext/gettext.html Awesome. I think that's just what I need for C/C++ stuff. > https://launchpad.net/php-gettext/ > > Oversimplifying... > > <?php > echo _("Hello World!"); > ?> > > This looks up the localized text for "Hello World!" in the translation > file and echos the translated text. That certainly seems simple enough! Sweet. > http://mel.melaxis.com/devblog/2005/08/06/localizing-php-web-sites-using-ge > ttext/ > > I realize you probably have no interest in the PHP bits of this Actually I do. It's true I'm not currently doing PHP development, but I am trying to package something that's in PHP... > , but I'm > putting it all here in case it's of some use to someone else. When I > first looked into this, it was not at all clear to me how exactly a GPL > program ought to do this in PHP. > > - Ron Yeah another interesting thing I've been running into concerning bash scripts are "Bash-isms"; because the default shell in Debian these days for package installation and /bin/sh (used for Cronjobs) is Dash -- not Bash. http://en.wikipedia.org/wiki/Debian_Almquist_shell There are some interesting differences, such as the lack of the "==" test, lack of "for" loops, etc. http://princessleia.com/plug/2008-JP_bash_vs_dash.pdf >From the above document I just found out there's a program 'checkbashisms' that helps with these things that's part of the 'devscripts' package. -- 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
