Flyspray - The bug killer!

“If debugging is the process of removing bugs, then programming must be the process of putting them in.” – Edsger Dijkstra

This is the Bug Tracking System for the Flyspray project. This is not a demo! Before opening a new task, please read the guidelines!

Do not issue bugs reports against versions earlier than 0.9.9.5

Security problem? Check the security section.

Tasklist

FS#293 - Separate i18n support files, and provide upload/install mechanism

Attached to Project: Flyspray - The bug killer!
Opened by Kostyuk Oleg (cub) - Friday, 02 July 2004, 08:59 GMT+1
Last edited by Tony Collins (knigits) - Monday, 20 December 2004, 23:31 GMT+1
Task Type Feature Request
Category User Interface
Status Closed
Assigned To No-one
Operating System All
Severity Low
Priority Normal
Reported Version 0.9.5
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

(see also #280)
May be, separate distribution for flyspray core and distribution for specific lang’s (except english) is good idea?
In that way, we take possibility release flyspray core independently from lang-pack’s and add new lang-pack’s for any version of flyspray after releasing core (non-simultaneously).

(sorry for my english:)

This task depends upon

Closed by  Tony Collins (knigits)
Monday, 30 January 2006, 08:06 GMT+1
Reason for closing:  Will Not Implement
Comment by Tony Collins (knigits) - Monday, 19 July 2004, 11:06 GMT+1

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

Comment by Kostyuk Oleg (cub) - Tuesday, 20 July 2004, 13:14 GMT+1

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” .
So, 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 langpack's.
Some 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 0.9.5?
And how other peoples, who use flyspray, get to known about it?
In mail-list? Okay, but how they will be install it? I’m sure, some not advansed users will try complette reinstall existing installation.
But if you separate distribution for core and langpack’s, and (may be) add web interface to install additional langpack - it will be very cool.

Comment by Tony Collins (knigits) - Wednesday, 25 August 2004, 02:43 GMT+1

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.

Comment by Kostyuk Oleg (cub) - Wednesday, 25 August 2004, 08:19 GMT+1

No-no.
None auto-updates, and even not auto-checks.
I see this in the following way.
When 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 langpack.
I can not download some langpack, but create it on one’s own - it’s not important.
Therefore, 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.

Comment by Tony Collins (knigits) - Thursday, 07 October 2004, 02:18 GMT+1

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.

Comment by Kostyuk Oleg (cub) - Tuesday, 19 October 2004, 14:43 GMT+1

For what zip-tools?
Why we can’t use system() call with regular tar/bzip2?...
It's will be runned only one time per install/upgrade - I thinks it’s acceptably.

Comment by Tony Collins (knigits) - Tuesday, 19 October 2004, 14:45 GMT+1

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

Comment by Kostyuk Oleg (cub) - Tuesday, 19 October 2004, 15:19 GMT+1

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

Comment by Tony Collins (knigits) - Tuesday, 19 October 2004, 22:34 GMT+1

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.

Comment by Kostyuk Oleg (cub) - Tuesday, 26 October 2004, 10:41 GMT+1

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?

Comment by Tony Collins (knigits) - Monday, 13 December 2004, 07:37 GMT+1

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.

Comment by Florian Schmitz (Floele) - Sunday, 29 January 2006, 16:27 GMT+1

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.

Loading...