Installation instructions on Ubuntu 10.04 server, and also on desktop, as these differ.

It needs a full story of how consultation notes work,
what the purpose of subscriptions is, and of assignments. Mention also that some people always put severity
to 'critical' even if their note describers a 'wish' only, so that a standard policy is recommended to be followed.




At this stage we can start to user Bibledit-Web for our consultation notes.
It should contain an improved replacement of Bibledit-Gtk for consultation notes.
To try out working with notes in Bibledit-Web, and with text in Bibledit-Gtk, whether that goes smoothly and easily,
in particular the navigation aspect.
Once notes work well in -Web, the sharing of these should be disabled in -Gtk, since it does not work reliably.



First release once we're satisfied that Bibledit-Web works as advertised.




Include backup of mysql into normal backup routines.
It should go as emailing it to localhost, then it is kept as email in Evolution.
It could be emailed every day. This should be an option set by the administrator, e.g. every two days, or every week.





Documentation should have diagrams (if these can be translated), .svg, inkscape or oodraw.








Notes should be exportable too, no: call  it 'backup' and 'restore'.
So we've got 'import', and then the 'backup' and 'restore'.











When reading the note git repository, it should note the notes marked NEW, their numbers, 
then check whether this number exists in the notes database already. If so, it needs to do special handling
to integrate this note: A new note is created, and the old one deleted.







The reference(s) of the note should get mailed out with the notifications.
Plus a link to the site, if this is possible.















Later, subscribers to a note do not get mail immediately. 
Rather changes to the notes are assembled into one message, and kept, 
and then sent out in one mail.
How this works is as follows:
A shadow table stores a copy of the note just before it changes.
Subsequent changes are not stored for as long as the initial copy is there.
What gets stored too is the time stamp of the last change.
The poor man's cron tab then check the changes every minute or so.
If it finds a last change older than, say, 5 minutes, then it mails out the difference to the users
subscribed, and erases the entry from the shadow database.








A system similar to the changes tracker for notes will work for changes in the text as well.
Let say, one hour after the last change in a chapter it will send out this chapter, along with any other
chapters, to the subscribed users.












Members can raise issues. If there are spammers, who made themselves a member,
then the manager can update their status so that it seems they log in, but in reality their submissions are ignored
and dropped.





When synchronizing the notes, note ID's can clash in cases that two or more users have created 
different notes but with the same identifier. When doing git commit, new note identifiers should be noted,
and when goint git pull, if these exist, that should be noted. But this will not work since the git pull
will already have merged the notes, thus leading to the loss of a note.
For that reason a list of new notes should be maintained, so that after git pull, this note is found to clash,
a new identifier is assigned to the note.











To automatically import translated templates from launchpad.
bzr init
bzr pull lp:~teusbenschop/bibledit/bibledit-pot
To import the translation templates into the source.








The site needs to have the concept of Desktops. Users can create store and erase these. 
E.g. a desktop for editing, one for merging, etc.
The desktops contain any combination of screens or tools that the user can use.
There are standard Desktops included in the default application. The user cannot modify these.
When editing desktops the user can choose in which menu it will be displayed, and it will be displayed there.






A user can subscribe to changes in a Bible.
These changes preferably are given only once an hour or so and the 
email will contain all changes assembled into one.
There will be links with the changes that allow the user to go straight to the passage.
Changes are given as in Bibledit-Gtk, where differences are shown till the character level.













Messaging between applications and server for e.g. verse reference, and many other things, 
e.g. lists of verses to be sent to the references window.





The text editor needs a link that sets the default / focused bible, so that the navigator takes that bible.
But for as long as the navigator is not yet separated, then this is not needed, but we should prepare for it in the code.





When collaborating, or setting it up, we need to set the php time out to 0 (inifinite)
Or better still would be to do as launchpad does, to start an independent process, and to monitor that through the page
and ajax polling.
This way there cannot be any timeouts, and the apache server remains free do continue serving other pages.
This requires a system for monitoring running tasks, and a page to monitor the information.
A database with task directories, outputs, and so on, deals with persistence.
Synchronisation processes probably can be started in parallel, but we must take care that the 
environmental variable for GIT is set each time rigth before a git application is called.














If a Bible translation work is collaborated in public domain, it could be too hard come up with one
translation for every verse. It  is too bad to split the team and make a copy of the web application 
every time they can not come up with a common translation. So I am assuming that branching at verse level
should be supported and the final outputs (like whole OSIS, let me call it "a distribution") should also be plural. 
And for each distribution should choose branched verses to take which version.



Just a thought here, but I think it might be good to have the option for administrators to chose which rights go to whom. 
E.g. I'm not sure a new translation really should be immediately available to anyone ("visitor"). 
It may invite premature comments or criticism that would slow the process down. 
Or perhaps visitors could be prevented entirely until a certain phase when the administrator chooses
to disclose translation content.












The book names are not localized as we do in bibledit-gtk, but localization uses the existing mechanism.
It works through gettext. For that reason a php file needs to be created that contains all existing English books.
This file is to be generated somehow by the system admin, and this file can be stored among the source code.
Thus the gettext system will be filled with that data, and can get translated.
If somebody wants the localized Bible names, but does not translate the whole site, it suffices to only translate 
the relevant bits in the po file.



















Pay attention to internationalization.
We need to get gettext working, and so need to have accounts where the user can set his language.
The administrator sets the default language for the site for guests and before login.


On Ubuntu for extra locales, install packages like "language-pack-*". After installing a new pack, run "locale-gen" and restart Apache (sudo apache2ctl restart)
to make this new locale to take effect. This should go in the installation manual.


To go through the various php functions called and read the comments, and learn from it.
setlocale(LC_ALL, ""); Takes the locale from the environment.
Before setting the locale, the php page runs 'locale -a' to see the available locales on the system.
Then, it needs to check whether bibledit provides this translation, and advise the user appropriately.

A little function to test available locales on a sytem :
<?php
function list_system_locales(){
    ob_start();
    system('locale -a'); 
    $str = ob_get_contents();
    ob_end_clean();
    return split("\\n", trim($str));
}

$locale = "fr_FR.UTF8";
$locales = list_system_locales();

if(in_array($locale, $locales)){
        echo "yes yes yes....";
}else{
        echo "no no no.......";
}
?>


It may use the available locales for dates and number representation as are on the system, and use our own locales 
as come with the application.
These two catalogs are different.





When setting translation domains in the preferences, do a check on the functions' return values if it worked out well.




The administrator can leave the locale empty, in which case the system locale will be taken. 
This should be the default for local installations.





The site has one default translation, set by the site administrator. Visitors get to see this default translation.




The purpose of the site is to inform the public about a translation in progress and to sollicit their input.
The 'consultation notes' on the site work in a special way. Contributors are invited to open an account on the site in order to contribute.
Consultation notes can be assigned to one or more persons. If a note is assigned to a person, then this person gets emailed.
But also, more importantly, the person will get reminders after e.g. a week, two weeks, a month. The person can set the frequency of
the reminders but not less often than once a month or two months on the most. This is the result that persons get regularly reminded if their
note has not been resolved. It is more a task than a note. Persons should also be able to click the 'resolved' button, which will 
automatically unassign it to him, and re-assign it to the 'team'. Borrow reasonably from a tickets system that may already be there.
There is also an array of users whose response is requested for this ticket, and reminders go to them till they respond by email or switch 
this flag off: Don't bother me with this ticket. If this flag is switched off by them, then they are regarded to have responded without a vote.
There is an external email account where email responses can go to, and this account is regularly checked by bibledit.
The ticket / issues trackers differs in model to the current system. The current system shares the notes, but the new system has a ticket number, 
with a variety of comments to it, and status. See the standard ticets systems. There should be a way to import the old system into the new.
The new should be shared also.







To have a Twitter module, that can send changes to twitter in a meaningful way.





To have a module that creates a new GoBible each hour if there were changes. The user also can request to make a module "now", 
which will be scheduled for the next minute. If there were no changes, it indicates this as well. There is also a very simple page for 
access from cell phones.





People with an account can subscribe to changes in the text, and to changes in the project notes. 
This is done in their account, under their email preferences.






Files in the web root should be given such a mode that these cannot be read from outside, only from inside.
This is: file permissions to -r--------.





The visitor to the site can see the default project, its text and comments. But to make comments, one has to get an account.
Those with an account have vastly improved opportonities on the site.






If a new version is installed, and routines are to be done, to be sure it always installs a file as a flag.
When this flag is found, the site says that after maintenance by the administrator it runs again (or similar).





















Windows: http://www.wampserver.com/
Or: http://www.apachefriends.org/en/xampp-windows.html
Easiest: EasyPHP.





Being behind a shaking connection, the site should be operatable by email as well, in particular the consultations.






Instead of using XeTeX, we could also look at CSS2 with paged media for printing, and screen media for the screen.








Where help is needed: 
Would need to write the software for the project under the GPL, stated in each source file.
Could fully test current source on Windows, describe how to install it, 
and create a Windows installer and describe how to do that through open source tools. 
Same for Macintosh. 
Would communicate through bibledit-development. 
Would write documentation on the Wiki. 
Could write manuals for how to work with Bibledit-Web. 
Could make a start with an issues tracker that is compatible with Bibledit-Gtk's project notes. 
He could enable internationalization and localization with a language setting in the user preferences, 
and a language setting for the site administrator for the site's language if the user has not yet logged in.






Bibledit-Web should have an administrative possibility to set the text that displays on the site to 
people not yet logged in, or logged out.





Importing USFM data should also be possible by file upload.
The file to be uploaded can be a plain text usfm file, possibly several books in one file,
or it could be compressed file, in which case Bibledit-Web will extract from that whatever it finds in that file.



When sending and receiving changes manually, it often will be forgotten.
It would be better to re-introduce the automatic version again.
This will result in better collaboration and less frustration if changes were not synchronized.



Mail received can accumulate in the Trash and get huge. There should be a link to empty the whole Trash 
in one go.
By default it should discard messages older than 30 days. It should mention this on the Trash page.




Mails to be sent out upon change in text. Can work now already, since there can be synchronisation 
with git repository. User may subscribe to any changes, or to changes per chapter.




The book names should be translatable. So it needs a list of all bible books to be included for gettext translation,
in .php format.




We may have to use vr.org for virtual servers for Ndebele translation hosting.





There can be a Notification setting that the user can set up which Bible or Bibles are included with the 
notifications on a note.




Installation documents for Bibledit-Web: Very often the installer has acces to the server through ssh only,
no GUI. Or even through ftp only, no option to install programs.




The Consultation Notes verse list, if the Verse List shows, 
then there is a link in the consultation notes [transfer to verses list],
which does what it says. This link is only shown if the verse list shows. If it does not show, then the link is not there.





Lower levels, such as member, only can 'add' a new verse to the existing verse list of the consultation note.
This is so that the 'member' cannot destroy the existing notes system.



Users should be able to create new status.
They can do this when changing the status: An option is offered to create a new one.




One of the last things that setup.php should do is to restart the poor man's crontab.



Bibledit-Web needs a setting where by it makes at midnight (or any time after), so many times a week,
a backup of the mysql table, zips these, and mails these out to an email address.



To implement the PHPUnit::tearDown function for where notes are created.





The changes of status should be added to the note text, just as if adding a comment.












The passages that are included with the note titles should be clickable so that if clicked,
the passages are loaded in the passages window.




It would be helpful if there were an 'update' menu for the administrator.
It would automatically update to, either the latest released version, or the development snapshot.




Producing a sword module for Katana.
Use usfm2osis.pl
If all .usfm files are in subdirectory ndebele, do this:
perl usfm2osis.pl Bible ndebele/*.usfm
This produces a file Bible.osis.xml.
Then make it a Sword module:
osis2mod . Bible.osis.xml
To write it to the proper place:
osis2mod ~/.sword/modules/texts/bibledit/ndebele Bible.osis.xml
Teus,
osis2mod is conservative with file permissions.  Be sure the files have
proper permissions before you deploy.
I only mention this because I often forget to grant read access to files
before deploying a module for testing and the result is only
chapter/verse numbers.
Troy
