From 70173af31924c52fbfb6bd41124ae70891a94cb9 Mon Sep 17 00:00:00 2001 From: bshuttle Date: Tue, 24 Jan 2006 09:38:46 +0000 Subject: [PATCH] - re-arrange the docs folder - add a INSTALL.WIN32.txt file - bump the version to 2.99.7 --- docs/Browse.txt | 40 ---------------------------------------- docs/CREDITS.txt | 6 ++++++ docs/INSTALL.WIN32.txt | 140 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ docs/INSTALL.txt | 9 +++++++++ docs/Permissions.txt | 72 ------------------------------------------------------------------------ docs/README.txt | 2 +- docs/RELEASE.txt | 25 ------------------------- docs/UPGRADE.txt | 7 +++++++ docs/VERSION.txt | 2 +- docs/codingStandards.txt | 13 ------------- docs/developer/Browse.txt | 40 ++++++++++++++++++++++++++++++++++++++++ docs/developer/Permissions.txt | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ docs/developer/RELEASE.txt | 25 +++++++++++++++++++++++++ docs/developer/codingStandards.txt | 13 +++++++++++++ docs/developer/i18n.txt | 34 ++++++++++++++++++++++++++++++++++ docs/developer/metadata-versions.txt | 28 ++++++++++++++++++++++++++++ docs/i18n.txt | 34 ---------------------------------- docs/metadata-versions.txt | 28 ---------------------------- 18 files changed, 376 insertions(+), 214 deletions(-) delete mode 100644 docs/Browse.txt create mode 100644 docs/INSTALL.WIN32.txt delete mode 100644 docs/Permissions.txt delete mode 100644 docs/RELEASE.txt delete mode 100644 docs/codingStandards.txt create mode 100644 docs/developer/Browse.txt create mode 100644 docs/developer/Permissions.txt create mode 100644 docs/developer/RELEASE.txt create mode 100644 docs/developer/codingStandards.txt create mode 100644 docs/developer/i18n.txt create mode 100644 docs/developer/metadata-versions.txt delete mode 100644 docs/i18n.txt delete mode 100644 docs/metadata-versions.txt diff --git a/docs/Browse.txt b/docs/Browse.txt deleted file mode 100644 index b0eadef..0000000 --- a/docs/Browse.txt +++ /dev/null @@ -1,40 +0,0 @@ -KT3 Browse System -================= - -KnowledgeTree's browse view has been a serious bottleneck in terms of -performance, and makes extending the system in useful ways (and re-using items) -unnecessarily hard. - -To understand this code, you'll need to look at: - - - lib/browse/DocumentCollection.inc.php - - lib/browse/BrowseColumns.inc.php - - presentation/.../browse.php - -Objectives of the refactor: - - - improve code-reuse - - make more advanced document-sets possible - - unify all document-collection logic (where possible). - -BROWSE VIEW GENERATION ----------------------- - -Generating a browse view is now done as follows: - - - create a DocumentCollection object - - add "BrowseColumns" to it. - - specify (on the collection) which column to sort on. - - specify any batching that may be required (count, start). - - execute the query (using generateCollection). - returns a set of document ids, in order (more info cached internally). - - for each row, use "getInfo(docid)" to extract the information from the database. - returns an array with info (more later), and caches this internally. - - at render-time, call "renderRow(docid)". - -Internally this does a fair bit more work. Particularly: - - - each Column can contribute JOINs, WHERE clauses. _if_ its the sort column, - it gets asked for an ORDER clause. - - the system fetches a LOT of information about each batched item - don't do too much. - diff --git a/docs/CREDITS.txt b/docs/CREDITS.txt index a787ae9..d0eaff6 100644 --- a/docs/CREDITS.txt +++ b/docs/CREDITS.txt @@ -5,3 +5,9 @@ phpmailer - http://phpmailer.sourceforge.net (LGPL) Mark Round's AuthLDAP class (class.AuthLDAP.php): http://phpclasses.dknss.com/browse/package/893.html (GPL) + +Javascript +MochiKit - http://www.mochikit.com/ (MIT License) +JS Calendar - http://dynarch.com/mishoo/calendar.epl (LGPL) +TinyMCE - http://sourceforge.net/projects/tinymce/ (LGPL) +Option Transfer Widget - http://www.mattkruse.com/ (Custom License) \ No newline at end of file diff --git a/docs/INSTALL.WIN32.txt b/docs/INSTALL.WIN32.txt new file mode 100644 index 0000000..9d63a49 --- /dev/null +++ b/docs/INSTALL.WIN32.txt @@ -0,0 +1,140 @@ +Windows Specific Installation Instructions +========================================== + +Installation on Windows XP and 2003 requires a slightly different approach to +the *NIX one. + +The easiest installation approach is to use our Windows installer. You can +find this for download on SourceForge, alongside our usual install bundles: + + http://sourceforge.net/projects/kt-dms + +Manual Install (XAMPP) +---------------------- + +If you need to do a manual installation of KnowledgeTree for some reason, +we recommend using a bundled version of Apache, MySQL and PHP. For testing +purposes, we use XAMPP (version 1.5.1): + + http://www.apachefriends.org/en/xampp.html + +General procedure: + + * Install XAMPP + + * Extract the KnowledgeTree zipfile inside the XAMPP htdocs directory. If + you installed XAMPP in + + c:\Program Files\xampp + + then you need to extract KnowledgeTree so that its files are in + + c:\Program Files\xampp\htdocs\knowledgeTree + + This will be referred to as "" in paths from here on. + + * Conduct the Pre-installation checkup. Assuming you are running XAMPP on + "localhost", visit + + http://localhost/knowledgeTree/setup/ + + * Configure the Database. The most effective way to do this with XAMPP is + to use phpmyadmin: + + http://localhost/phpmyadmin/ + + 1. Create a new database (call it "dms") + 2. Create the tables: + + - open the "dms" database from the left-menu/. + - go to "SQL" at the top of the screen. + - Where it says "Location of the text file" click browse and then run: + + * \sql\mysql\install\structure.sql + * \sql\mysql\install\data.sql + * \sql\mysql\install\user.sql + + * Configure your installation in config\config.ini: + + - The default configuration will determine many settings on your + installation automatically, and this is the preferred method of + running KnowledgeTree. Please do not manually set these settings + unless you know what you are doing. + + - The default configuration uses the database username and password + in the user.sql file mentioned above, use the local host for the + database, and use the database named 'dms'. If you follow the + examples above in setting up the database, this means KnowledgeTree + should be fully configured to start working. + + - However, you should change this once you've performed your initial + evalution of KnowledgeTree for the security of your documents. + + - The following settings in config/environment.php control the + database connectivity, and can be set as shown: + + [db] + dbHost = localhost + dbName = dms + dbUser = myuser + dbPass = mypassword + + * Check the post-installation checklist: + + If your knowledgeTree installation is at http://localhost/, go to: + + http://localhost/setup/ + + And click on "Post-installation checkup". + + * Login: + - in a web browser go to your KnowledgeTree installation via the web + - default user is "admin" with password "admin" + + * Register the standard plugins. + + - in a web browser go to "DMS Administration" , then "Miscellaneous", + then "Manage Plugins" + - click "Reread plugins" to load the list of available plugins. + - enable the plugins as required. + + * Please note: * + Fulltext indexing of files (e.g. checking their contents) needs to be + activated from this menu or the full-text search WILL NOT work. + + +File Indexing +------------- + +The file indexing facilities of KnowledgeTree make use of external +programs to perform their jobs. + +At the moment, the "catdoc" (http://www.45.free.net/~vitus/ice/catdoc/) +and "xpdf" packages contains all the external programs you need. +Installing this package is beyond the scope of this document - please +consult the KnowledgeTree Wiki at http://support.ktdms.com/confluence/ +to see how others have approached this on your platform. + +You can find Windows specific installation instructions here: + + http://support.ktdms.com/confluence/display/KTWiki/Windows+XP+installation+instructions + + +Troubleshooting +--------------- + +Please make sure that your KnowledgeTree installation passes all the +pre- and post-installation checkups first. + +Refer to the Frequently Asked Questions list on the KnowledgeTree Wiki +at http://support.ktdms.com/confluence/ + +Ask on the KnowledgeTree forums on http://forum.ktdms.com/. + +If you have found a bug, please report it to the KnowledgeTree bug +reporting system at http://support.ktdms.com/. + +Upgrading +--------- + +Refer to docs/UPGRADE.txt diff --git a/docs/INSTALL.txt b/docs/INSTALL.txt index a2ca236..ee88c4c 100644 --- a/docs/INSTALL.txt +++ b/docs/INSTALL.txt @@ -99,6 +99,15 @@ KnowledgeTree Installation Notes - in a web browser go to your KnowledgeTree installation via the web - default user is "admin" with password "admin" +* Register the standard plugins. + - in a web browser go to "DMS Administration" , then "Miscellaneous", + then "Manage Plugins" + - click "Reread plugins" to load the list of available plugins. + - enable the plugins as required. + + * Please note: * + Fulltext indexing of files (e.g. checking their contents) needs to be + activated from this menu or the full-text search WILL NOT work. File Indexing ------------- diff --git a/docs/Permissions.txt b/docs/Permissions.txt deleted file mode 100644 index ca1c73a..0000000 --- a/docs/Permissions.txt +++ /dev/null @@ -1,72 +0,0 @@ -KnowledgeTree Permission System -=============================== - -Permission Object ------------------ -Permissions on items in the DMS are handled via a Permission Object. -This permission object is where the permissions for the object are kept. -Previously, a permission folder was used, but this was changed to an -autonomous permission object to allow greater flexibility - such as -allowing documents to have their own permissions in future. - -Permission Assignments ----------------------- -This permission object links the item with a number of permission -assignments - one permission assignment per permission. A permission -assignment is uniquely specified by a permission object and a -permission. The final component is a permission descriptor, which -describes the groups, users, or roles that have that permission on that -permission object. - -Permission Descriptor ---------------------- -The permission descriptor is an indirection to reduce the number of rows -to describe which groups, users, and roles that have permissions on each -permission object. It allows assignments that cover the same groups, -users, and roles to be described textually and looked up quickly by a 32 -character hash. A particular collection of groups, users, and roles -will always be described by a unique descriptor. - -Permission Lookup ------------------ -Permission Lookup objects describe the collections of groups and users -that have each permission on the item in the repository. It is an -expanded form of the permission object - if an owner role has a -permission in terms of the permission object, the exact user with that -role on that object will be mentioned in the permission lookup. - -Permission lookups exist mostly for restricting a search for items in -the repository to those items for whom a particular user has a given -permission. The most obvious users of this are the content and metadata -searches, which need to restrict results to documents readable by the -current user. Other users may be the list of documents in a folder -readable by the current user, or the list of folders in the repository -that the user can add documents to. - -Managing Permissions --------------------- - -Permission lookups use descriptors that never expand groups. Changes in -membership of a group don't require permission lookups. When looking up -using permission lookups, the descriptors that the user has access to -are looked up at run-time first, and these are used to limit the -searches. - -On creation, folders and documents inherit the permission object of -their parent. They then update their own permission lookups. -(Document::create, Folder::create) - -When folders change their permission object (become their own master, -start using their parent again, are moved), they update all ancestor -folders and documents that had the old permission object to the new one. -Those changed then have their permission lookups updated. -(KTPermissionUtil::copyPermissionObject, -KTPermissionUtil::inheritPermissionObject) - -When documents change their permission object (become their own master, -start using their parent again, are moved), they update their own -permission lookups. -(KTPermissionUtil::copyPermissionObject, -KTPermissionUtil::inheritPermissionObject) - - diff --git a/docs/README.txt b/docs/README.txt index 1f80256..9c36a76 100644 --- a/docs/README.txt +++ b/docs/README.txt @@ -1,7 +1,7 @@ KnowledgeTree Document Management System ---------------------------------------- -Welcome to the first KnowledgeTree 3 beta. While it represents a +Welcome to the fourth KnowledgeTree 3 beta. While it represents a significant improvement to the visible and background components of KnowledgeTree, it is not yet ready for production use. It is recommended that you ensure you have backups of anything you put into diff --git a/docs/RELEASE.txt b/docs/RELEASE.txt deleted file mode 100644 index dfbcb55..0000000 --- a/docs/RELEASE.txt +++ /dev/null @@ -1,25 +0,0 @@ -Here is the release process for KnowledgeTree. - -Test: -1.1. Testing. - -Prepare: -2.1. Update Changelog. -2.2. Put release date into Changelog.txt -2.3. Update database install and upgrade SQL scripts -2.4. Update version number in database install and upgrade scripts -2.5. Tag CVS - RELEASE_1_2_3_20040909 -2.6. kt/releaseKT.sh -b RELEASE_1_2_3_20040909 -v 1.2.3 -2.7. Test final release - -Release: -3.1. ncftpput upload.sourceforge.net /incoming knowledgeTree-1.2.3.tgz knowledgeTree-1.2.3.zip -3.2. Add to Sourceforge file manager -3.3. Update Web site version number and features. - -Inform: -4.1. Mail kt-dms-users and kt-dms-developers and kt-dms-announce -4.2. Add to Forums - -Post-release: -5.1. Prepare Changelog.txt for next release diff --git a/docs/UPGRADE.txt b/docs/UPGRADE.txt index 5660a65..bd5479a 100644 --- a/docs/UPGRADE.txt +++ b/docs/UPGRADE.txt @@ -1,6 +1,13 @@ KnowledgeTree Upgrade instructions ================================== +* Please Note that KT3 Beta 4 is the first post-2.0.x version to support + a sane upgrade path. WE STRONGLY RECOMMEND YOU MAKE A BACKUP BEFORE + YOU START. Please help us by submitting any bugs you find in the migration + process at + + http://support.ktdms.com + Before you upgrade ------------------ diff --git a/docs/VERSION.txt b/docs/VERSION.txt index da35147..bbb1516 100644 --- a/docs/VERSION.txt +++ b/docs/VERSION.txt @@ -1 +1 @@ -2.99.6-20050120-8 +2.99.7 diff --git a/docs/codingStandards.txt b/docs/codingStandards.txt deleted file mode 100644 index 77f457f..0000000 --- a/docs/codingStandards.txt +++ /dev/null @@ -1,13 +0,0 @@ -Coding Standard Doc -===================== -(Inform - can be formalized later. Only standards above and beyond those in the original spec are included here) - -1) All functions return their required value on success or false otherwise. On returning false, all function - set the $_SESSION["errorMessage"] variable -2) All presentation layer files must contain a list of the expected querystring and form variables they will receive -3) Any function that inserts into a database table must begin its name with "create" e.g. createFolder(). The exception - to this is a function which inserts into a link table. It must begin its name with "add" e.g. addUserToGroup() -4) All database tables that consist of id, name pairs will end in the word "lookup" e.g. groups_lookup -5) All database tables that link two or more tables together will end in the word "link" -6) When using the @return tag in the case of mixed return types, the return type should always be the - type that is returned if the function succeedes i.e. does what it is supposed to do diff --git a/docs/developer/Browse.txt b/docs/developer/Browse.txt new file mode 100644 index 0000000..b0eadef --- /dev/null +++ b/docs/developer/Browse.txt @@ -0,0 +1,40 @@ +KT3 Browse System +================= + +KnowledgeTree's browse view has been a serious bottleneck in terms of +performance, and makes extending the system in useful ways (and re-using items) +unnecessarily hard. + +To understand this code, you'll need to look at: + + - lib/browse/DocumentCollection.inc.php + - lib/browse/BrowseColumns.inc.php + - presentation/.../browse.php + +Objectives of the refactor: + + - improve code-reuse + - make more advanced document-sets possible + - unify all document-collection logic (where possible). + +BROWSE VIEW GENERATION +---------------------- + +Generating a browse view is now done as follows: + + - create a DocumentCollection object + - add "BrowseColumns" to it. + - specify (on the collection) which column to sort on. + - specify any batching that may be required (count, start). + - execute the query (using generateCollection). + returns a set of document ids, in order (more info cached internally). + - for each row, use "getInfo(docid)" to extract the information from the database. + returns an array with info (more later), and caches this internally. + - at render-time, call "renderRow(docid)". + +Internally this does a fair bit more work. Particularly: + + - each Column can contribute JOINs, WHERE clauses. _if_ its the sort column, + it gets asked for an ORDER clause. + - the system fetches a LOT of information about each batched item - don't do too much. + diff --git a/docs/developer/Permissions.txt b/docs/developer/Permissions.txt new file mode 100644 index 0000000..ca1c73a --- /dev/null +++ b/docs/developer/Permissions.txt @@ -0,0 +1,72 @@ +KnowledgeTree Permission System +=============================== + +Permission Object +----------------- +Permissions on items in the DMS are handled via a Permission Object. +This permission object is where the permissions for the object are kept. +Previously, a permission folder was used, but this was changed to an +autonomous permission object to allow greater flexibility - such as +allowing documents to have their own permissions in future. + +Permission Assignments +---------------------- +This permission object links the item with a number of permission +assignments - one permission assignment per permission. A permission +assignment is uniquely specified by a permission object and a +permission. The final component is a permission descriptor, which +describes the groups, users, or roles that have that permission on that +permission object. + +Permission Descriptor +--------------------- +The permission descriptor is an indirection to reduce the number of rows +to describe which groups, users, and roles that have permissions on each +permission object. It allows assignments that cover the same groups, +users, and roles to be described textually and looked up quickly by a 32 +character hash. A particular collection of groups, users, and roles +will always be described by a unique descriptor. + +Permission Lookup +----------------- +Permission Lookup objects describe the collections of groups and users +that have each permission on the item in the repository. It is an +expanded form of the permission object - if an owner role has a +permission in terms of the permission object, the exact user with that +role on that object will be mentioned in the permission lookup. + +Permission lookups exist mostly for restricting a search for items in +the repository to those items for whom a particular user has a given +permission. The most obvious users of this are the content and metadata +searches, which need to restrict results to documents readable by the +current user. Other users may be the list of documents in a folder +readable by the current user, or the list of folders in the repository +that the user can add documents to. + +Managing Permissions +-------------------- + +Permission lookups use descriptors that never expand groups. Changes in +membership of a group don't require permission lookups. When looking up +using permission lookups, the descriptors that the user has access to +are looked up at run-time first, and these are used to limit the +searches. + +On creation, folders and documents inherit the permission object of +their parent. They then update their own permission lookups. +(Document::create, Folder::create) + +When folders change their permission object (become their own master, +start using their parent again, are moved), they update all ancestor +folders and documents that had the old permission object to the new one. +Those changed then have their permission lookups updated. +(KTPermissionUtil::copyPermissionObject, +KTPermissionUtil::inheritPermissionObject) + +When documents change their permission object (become their own master, +start using their parent again, are moved), they update their own +permission lookups. +(KTPermissionUtil::copyPermissionObject, +KTPermissionUtil::inheritPermissionObject) + + diff --git a/docs/developer/RELEASE.txt b/docs/developer/RELEASE.txt new file mode 100644 index 0000000..dfbcb55 --- /dev/null +++ b/docs/developer/RELEASE.txt @@ -0,0 +1,25 @@ +Here is the release process for KnowledgeTree. + +Test: +1.1. Testing. + +Prepare: +2.1. Update Changelog. +2.2. Put release date into Changelog.txt +2.3. Update database install and upgrade SQL scripts +2.4. Update version number in database install and upgrade scripts +2.5. Tag CVS - RELEASE_1_2_3_20040909 +2.6. kt/releaseKT.sh -b RELEASE_1_2_3_20040909 -v 1.2.3 +2.7. Test final release + +Release: +3.1. ncftpput upload.sourceforge.net /incoming knowledgeTree-1.2.3.tgz knowledgeTree-1.2.3.zip +3.2. Add to Sourceforge file manager +3.3. Update Web site version number and features. + +Inform: +4.1. Mail kt-dms-users and kt-dms-developers and kt-dms-announce +4.2. Add to Forums + +Post-release: +5.1. Prepare Changelog.txt for next release diff --git a/docs/developer/codingStandards.txt b/docs/developer/codingStandards.txt new file mode 100644 index 0000000..77f457f --- /dev/null +++ b/docs/developer/codingStandards.txt @@ -0,0 +1,13 @@ +Coding Standard Doc +===================== +(Inform - can be formalized later. Only standards above and beyond those in the original spec are included here) + +1) All functions return their required value on success or false otherwise. On returning false, all function + set the $_SESSION["errorMessage"] variable +2) All presentation layer files must contain a list of the expected querystring and form variables they will receive +3) Any function that inserts into a database table must begin its name with "create" e.g. createFolder(). The exception + to this is a function which inserts into a link table. It must begin its name with "add" e.g. addUserToGroup() +4) All database tables that consist of id, name pairs will end in the word "lookup" e.g. groups_lookup +5) All database tables that link two or more tables together will end in the word "link" +6) When using the @return tag in the case of mixed return types, the return type should always be the + type that is returned if the function succeedes i.e. does what it is supposed to do diff --git a/docs/developer/i18n.txt b/docs/developer/i18n.txt new file mode 100644 index 0000000..c325339 --- /dev/null +++ b/docs/developer/i18n.txt @@ -0,0 +1,34 @@ +KnowledgeTree Internationalisation (i18n) +----------------------------------------- + +KnowledgeTree 3 beta 1 contains many non-internationalised texts, for +example within templates. We would appreciate input on how best to +approach internationalisation within templates. Please use the +KnowledgeTree forums at http://forum.ktdms.com/ to discuss +internationalisation. + +Testing +------- +- install gettext command line utilities +- run xgettext to generate .po files eg. +Neil quite likes: + $ find . -type f | xgettext --no-wrap -d knowledgeTree -L PHP -s -f - -o i18n/knowledgeTree.po + +Michael was using: + xgettext --files-from=i18n/file-list -LPHP --keyword=_ --no-wrap --msgid-bugs-address="kt-i18n@jamwarehouse.com" -o knowledgeTree.po + +- write a test translation by editing the po file appropriately. if you have problems with the order of parameters, because your language's + ordering is different then in english. You can use the $ to change order eg: + msgid "Upgrading item %d of %d" + msgstr "... %2$d ... %1$d ..." +- construct the right directory structure inside i18n eg. + $ mkdir -p i18n/es/LC_MESSAGES/ +- upgrade the existing .po files in each translation using: + $ mv knowledgeTree.po old.po + $ msgmerge --no-wrap old.po ../knowledgeTree.po --output-file=knowledgeTree.po + $ rm old.po +- use msgfmt to compile your translated .po file to a .mo + $ msgfmt --check $knowldgeTree.po --output-file=i18n/$es/LC_MESSAGES/knowledgeTree.mo +- change $default->defaultLanguage in config/environment.php and verify your translation. + +$Id$ diff --git a/docs/developer/metadata-versions.txt b/docs/developer/metadata-versions.txt new file mode 100644 index 0000000..30e52a7 --- /dev/null +++ b/docs/developer/metadata-versions.txt @@ -0,0 +1,28 @@ +Metadata versions +================= + +KnowledgeTree can keep a historic view of both the physical document and +the associated metadata. + +Version creation +---------------- +Metadata versions need to occur when: +- A new physical document is added +- Metadata is changed + +Database effects +---------------- +Metadata versions are stored in the standard documents table, with the +document status set to STATUS_HISTORY (6). Metadata versions are copies +of the document table currently, and all associated generic and +type-specific metadata. Each metadata version has its own metadata +version number (metadata_version, getMetadataVersion()). + +This configuration makes searches much easier. + +Interface changes +----------------- +Metadata versions are listed in the document detail view under "Metadata +Versions". When selected, the document detail view is updated to place +the metadata version on the right-hand side of the view, allowing +comparison. diff --git a/docs/i18n.txt b/docs/i18n.txt deleted file mode 100644 index c325339..0000000 --- a/docs/i18n.txt +++ /dev/null @@ -1,34 +0,0 @@ -KnowledgeTree Internationalisation (i18n) ------------------------------------------ - -KnowledgeTree 3 beta 1 contains many non-internationalised texts, for -example within templates. We would appreciate input on how best to -approach internationalisation within templates. Please use the -KnowledgeTree forums at http://forum.ktdms.com/ to discuss -internationalisation. - -Testing -------- -- install gettext command line utilities -- run xgettext to generate .po files eg. -Neil quite likes: - $ find . -type f | xgettext --no-wrap -d knowledgeTree -L PHP -s -f - -o i18n/knowledgeTree.po - -Michael was using: - xgettext --files-from=i18n/file-list -LPHP --keyword=_ --no-wrap --msgid-bugs-address="kt-i18n@jamwarehouse.com" -o knowledgeTree.po - -- write a test translation by editing the po file appropriately. if you have problems with the order of parameters, because your language's - ordering is different then in english. You can use the $ to change order eg: - msgid "Upgrading item %d of %d" - msgstr "... %2$d ... %1$d ..." -- construct the right directory structure inside i18n eg. - $ mkdir -p i18n/es/LC_MESSAGES/ -- upgrade the existing .po files in each translation using: - $ mv knowledgeTree.po old.po - $ msgmerge --no-wrap old.po ../knowledgeTree.po --output-file=knowledgeTree.po - $ rm old.po -- use msgfmt to compile your translated .po file to a .mo - $ msgfmt --check $knowldgeTree.po --output-file=i18n/$es/LC_MESSAGES/knowledgeTree.mo -- change $default->defaultLanguage in config/environment.php and verify your translation. - -$Id$ diff --git a/docs/metadata-versions.txt b/docs/metadata-versions.txt deleted file mode 100644 index 30e52a7..0000000 --- a/docs/metadata-versions.txt +++ /dev/null @@ -1,28 +0,0 @@ -Metadata versions -================= - -KnowledgeTree can keep a historic view of both the physical document and -the associated metadata. - -Version creation ----------------- -Metadata versions need to occur when: -- A new physical document is added -- Metadata is changed - -Database effects ----------------- -Metadata versions are stored in the standard documents table, with the -document status set to STATUS_HISTORY (6). Metadata versions are copies -of the document table currently, and all associated generic and -type-specific metadata. Each metadata version has its own metadata -version number (metadata_version, getMetadataVersion()). - -This configuration makes searches much easier. - -Interface changes ------------------ -Metadata versions are listed in the document detail view under "Metadata -Versions". When selected, the document detail view is updated to place -the metadata version on the right-hand side of the view, allowing -comparison. -- libgit2 0.21.4