




Consider creating the headers and footers just to assist those who need to typeset.
Could be created from a template just by updating some sizes manually, e.g. 
styles.xml with str_replace.
Start on this when neeeded.















Notes date selection mechanism: 
Those which have not had any activity on them for, e.g., a week or more, or a month or more.












The sorting of the notes is not right yet. It should sort chapters and verses numerically.












Export the USFM data to the .exp file for the Online Bible.
See OLB Help/Table Of Contents/How To/Create Your Own Bible.













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
















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.
Perhaps this can be implemented by storing another Bible as an overlay, which only has a few verses, namely
the verses that differ. The base Bible is used, then the overlay is applied to it, and then the output is generated.
















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.




















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.




















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















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 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.












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
























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.















> Is there any news about packing bibledit-web? 

CONFIGURING TOO EARLY:

Looking further at the autotools configuration done in bibletime-web
0.2, other things that need to be settable per-installation, not at
build time, are apparently also being configured and defined at build
time.  These include the database server location, database admin user,
database admin password, database name, database user, database
password, bibledit admin user and password, and the location of the
webroot of the web server.  Some of these seem to be handled in
database/credentials.php and this is created by setup.php, but in that
case, why is the checking of MySQL at build time being done?

Why the code needs the mysql admin username and pw is a question in
itself -- wouldn't it be more secure to prompt for these when needed,
which hopefully is just for a one-time initial database setup, done at
(package) install time, not build time?

Since (at least in theory) one could set up multiple instances of
bibledit-web on a single server, each with their own database and each
with their own apache virtualhost, doing too much at build time seems to
me to reduce overall flexibility and capability.

Unless I am misunderstanding what the code does, I don't see how this
software can readily be packaged until many or all of these things are
moved from being defined and checked at build time to being settable in
a configuration file accessed (and checked, if appropriate) at run time.

DATABASE CREATION:

I think the setup.php code that creates the bibledit-web database
probably will need to be made usable as a script to be run at package
installation time, or maybe at first web login to bibledit-web.  Asking
users to point a browser at a URL just to do something non-interactive
seems unfriendly.  The web server needing to be able to delete the
bibledit-web php files (auto-deleting setup.php after running it) looks
like a security weakness; only the server admin should be able to edit
or delete those files, once installed.

LACK OF $(DESTDIR):

I've also found what seems to be the same kind of issue I found earlier
in the bibledit-gtk Makefiles, where an install-data-local target does
not use $(DESTDIR).  This time the issue is in web/Makefile.am where the
four lines under the install-data-local: target need $(DESTDIR) before
$(WEBROOT).

Fixing that still leaves it installing directly into the root of the
default host, /var/www/, which is not allowed, but that's a different
issue, more related to the "configuring too early" problem noted above.

SECURITY:

There is too much chmod -R 0777 going on (both in the Makefiles and then
also in some PHP code) than can be considered safe or secure for an
Internet-facing web server.  World writable files and directories are
almost never needed, and almost always a security risk.  Why would every
user on the web server machine need full access to all of these
bibledit-web files and directories?  Installed on a shared web hosting
server, this could quite easily allow other customers on that server to
do anything they like with your site, including add their own code, run
spambots as you, hand out malware to every unsuspecting user who uses
the bibledit-web site, etc.

I'm not sure that suggesting or assuming a MySQL root pw of "root" is
wise, either :)  If you are going to do setup from PHP, why not have
setup.php prompt for all the database info (host, dbname, adminuser,
adminpw, username, pw) and write some of it (hopefully not the
adminuser/adminpw!) to a config file?  It can do some of that already.

All uses of system() and exec() should probably specify a full path, so
users can't persuade your code to execute *their* chmod instead of the
system one, for instance.

I'd suggest you try to do a detailed security review as soon as
practical.  It seems odd to be using 1024bit ssh keypairs, but also
doing things like "chmod 0777" and assuming a dba password of "root".

INSTALLATION HELP:

The help button points to help/001ubuntu1004server.php but this is
specifically for 0.1, and the codebase is 0.2.  Are there any
differences?  Also, this file says in part:

  If the site is "site.com", then this will be something like:
  http://site.org/bibledit/setup.php

You can use either site.org or site.com, but they need to match :)
Using example.com is common for this kind of text, incidentally.

SUMMARY:

As far as I can see, the bibledit-web 0.2 codebase pretty much requires
that it be built from source, locally for each individual installation.
 That is the exact opposite of what packaged software does (build it
once, then distribute the resulting compiled binary package around the
world) :)  Since bibledit-gtk doesn't require this
unique-per-installation build, I'm not sure why bibledit-web does, or
what the benefit of this approach is.  I rather suspect that in trying
to make things "friendly" for people installing it from source, the
software has been made hard or impossible to install as a package.

Hoping we can find a good approach to packaging bibledit-web,




I now have a hacked-up bibledit-web 0.2 package that more-or-less does
what the source install does, and installs on a test virtual server.
But it's much too rough to release, it breaks many rules, and won't even
build in a PPA, never mind in the official builders.

A few more comments and questions arising from this:

DATABASE CREATION vs DATABASE USE:

I am rather alarmed to find that the bibledit-web code seems to make no
distinction between the database user/pw needed to create the bibledit
database and its tables, at install time, and the one used at runtime to
work with those tables.  Am I understanding this correctly?

By default, this leads to the bibledit-web database code using the
all-powerful DBA user (root) at run-time, and storing that username and
*password* in plain text in a configuration file.  Worse still, the
default password is "root", and (even worse!) that configuration file is
set to mode 0777, so absolutely any user on the server can read it, and
then use it to do absolutely anything they want with any MySQL database
on that database server.

I believe this is a significant security issue.  On my web servers
(servers I admin, not servers I own!), a single MySQL server instance
can contain databases for 100-200 independently owned web sites... the
bibledit-web 0.2 installation in effect gives *every* user on the server
full access to *every* *single* *one* of those databases! (I didn't
install bibledit-web on a production server, so no harm done, I'm just
pointing out how bad this would be in production use!).

I think the right solution is for the code to distinguish very clearly
between (a) the DBA username and pw, and (b) the runtime
bibletime-specific user and pw.  (a) is prompted for and used only once,
at install time, to create the bibledit database and the runtime user
and pw. It is never stored anywhere on disk.  (b) is then used to create
the tables, and then to access the information in database, by
bibledit-web at runtime.  It is stored in a config file (readable only
by the user running the bibledit virtualhost, but not by others!).

I have not checked whether this issue is fixed in the latest git
development code; I probably should :)

LIBRARIES:

Is there a list somewhere of what libraries are needed by bibledit-web,
or are incorporated as copies (or modified copies) within it?  So far I
have found:

 * jquery
 * jwysiwyg (a plugin for jquery)
 * a modified copy of part of zendframework

Are there any more?  At least the non-modified ones have to be packaged
separately, if packaged versions of them don't already exist.  And I'll
have to look at the modified ZendFramework code and see how best to
proceed there.  The INSTALL file might be a reasonable place to put this
kind of information.
Ubuntu has libzend-framework-php




















Crash in Bibledit-Gtk when doing a merge, then clicking in an Editor.












OpenOffice may export to PDF, probably, see unoconv.
This PDF looks better than the one made through cups-pdf.







