Flyspray

Isn’t this the way it’s done already?

As you say in #280, “translators should be subscribed to the mailing list and wait for me to say that the next release is ready to translate”
I think, release of FlySpray will be complette at all not when core release ready, but only when translators done - it’s right? And in addition, translators have limited time, right?

The heart of my proposition - _separate_ core and
like to

flyspray-0.9.6-core.tar.gz
flyspray-0.9.6-lang-ru.tar.gz
flyspray-0.9.6-lang-it.tar.gz
flyspray-0.9.6-lang-pl.tar.gz

and include only english langpack to core distribution.

In that way, no need to wait translators for releasing core o FlySpray, no need to include langpacks to core distribution, and langpack for any version can be added at any time after releasing core. We will take independence core and langpack’s.

For example, now I have russian translation for 0.9.5 - how you can add it to release
how other peoples, who use flyspray, get to known about
mail-list? Okay, but how they will be install it? I’m sure, some not advansed users will try complette reinstall existing
if you separate distribution for core and langpack’s, and (may be) add web interface to install additional langpack - it will be very cool.

Are you asking for Flyspray to automatically check for updates and new translations, and have the ability to download and install them? I can certainly set up a system to check for new updates/translations, but I don’t think Flyspray should do installations. System administrators should always check their download before adding it to a live server.

auto-updates, and even not
see this in the following
I get to known about releasing new version of langpack (in some way - from maillist, from friens, and so on), I visit FS homepage and download langpack file to localhost. After analyzing downloaded file, I go to my local FS as admin and upload this file on special page. When my local FS get this file, it unpack and install this
can not download some langpack, but create it on one’s own - it’s not
we need establish format of upgrade files.

NB: same technics we can use to upload new themes/skins and feature extensions - even for upgrade core of FS.

I understand what you want. http://www.php.net/manual/en/ref.zip.php says that the unzip tools do not come standard with php, which means that it would add another dependency to Flyspray. I don’t like additional dependencies, especially ones that aren’t included on my web hosting.

I welcome suggestions on alternative ways to implement this task.

For what
we can’t use system() call with regular
will be runned only one time per install/upgrade - I thinks it’s acceptably.

Win32 systems don’t have tar, gzip or bzip2...

Ok, so we have two opportunity 1) decline this feature 2) support it for *nix platforms and not support for
selection?

I don’t want to decline it, as it sounds like a good idea. However, I won’t implement something that doesn’t work on both nix and win. I’m still open to more ideas on how to do it.

Ok, I can propose one more opportunity - detect is it zip-tools present in current php installation or not, and depending on this - enable this feature, on disable...

In other words, we can have link to upgrading page always enabled, but detect availability of zip-tools on the fly and determine content of this page depending of results:

when zip-tools/tar/gzip/bzip/etc available, show upgrading page
when they unavailable, show explanation and propose install zip-toos to activate this fweature.

Is this acceptable for you?

I’m told that PEAR has a module for working with zip files. We’re currently looking at a few other PEAR modules, so we might look at this one too.

I suggest to close this task as “won’t implement”. “Installing” new language files is so simple now (upload one single file) that I don’t see a need to privide an upload and install mechanism. We can add a readme.txt to each language pack which tells the user where to upload the file.