



To create Bibledit-Paratext by cloning existing software. Should not be a huge lot of work.








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.














Sending out changes to the text.
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.
















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.


















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.












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.



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.








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.








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













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




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
