How to Update the translations

Prev	Chapter 16. Releasing OpenACS	Next

- -

-
Identify any new locales that have been created. +How to Update the translations
Prev Chapter 16. Releasing OpenACS Next
How to Update the translations
1. Identify any new locales that have been created. For each new locale, check the parameters, especially that the locale is in the format [two-letter code for language, lower-case]_[TWO-LETTER CODE FOR COUNTRY, UPPER-CASE], and create a sql command. A - example sql command for creating a locale is:
  -
```
insert into ad_locales 
+        example sql command for creating a locale is:
insert into ad_locales 
        (locale, label, language, country, nls_language, nls_territory, 
         nls_charset, mime_charset, default_p, enabled_p)
        values ('fa_IR', 'Farsi (IR)', 'fa', 'IR', 'FARSI', 'IRAN', 'AL24UTFFSS', 
-        'windows-1256', 't', 'f');
-        Put this command into the following four files.  For the
+        'windows-1256', 't', 'f');
```
  Put this command into the following four files. For the upgrade files, the correct file name will depend on the - exact version.
  -
  -
  /packages/acs-lang/sql/postgresql/ad-locales.sql
  -
  -
  /packages/acs-lang/sql/postgresql/upgrade/upgrade-current-version.sql
  -
  -
  /packages/acs-lang/sql/oracle/ad-locales.sql
  -
  -
  /packages/acs-lang/sql/oracle/upgrade/upgrade-current-version.sql
  -
  -
2. -
  Make a backup of the production database. Restore it as a new database. For example, if upgrading from OpenACS 5.1.1, and the site name/database name is translate-511, create translate-512b1.
  -
3. -
  Check out the latest code on the release branch (e.g., oacs-5-1) as a new site, using the new site name (e.g., /var/lib/aolserver/translate-512b1. Copy over any local settings - usually, /etc/config.tcl and /etc/daemontools/run and modify appropriately. Also, copy over several translation-server-only files: + exact version.
  /packages/acs-lang/sql/postgresql/ad-locales.sql
  /packages/acs-lang/sql/postgresql/upgrade/upgrade-current-version.sql
  /packages/acs-lang/sql/oracle/ad-locales.sql
  /packages/acs-lang/sql/oracle/upgrade/upgrade-current-version.sql
4. Make a backup of the production database. Restore it as a new database. For example, if upgrading from OpenACS 5.1.1, and the site name/database name is translate-511, create translate-512b1.
5. Check out the latest code on the release branch (e.g., oacs-5-1) as a new site, using the new site name (e.g., /var/lib/aolserver/translate-512b1. Copy over any local settings - usually, /etc/config.tcl and /etc/daemontools/run and modify appropriately. Also, copy over several translation-server-only files:
```
...TBD
           
```
  -
  -
6. -
  Shut down the production site and put up a notice (no procedure on how to do this yet.)
  -
7. -
  Start the new site, and upgrade it.
  -
8. -
  Go to ACS Lang admin page and click "Import All Messages"
  -
9. -
  Resolve conflicts, if any, on the provided page. -
  -
10. -
  Back on the admin page, click the export link. If there are conflicts, the messages will be exported anyway and any errors will be shown in the web interface.
  -
11. -
  Commit the message catalogs to cvs.
  -
12. -
  From the packages dir, run the acs-lang/bin/check-catalog.sh script. (This checks for keys no longer in use and some other things. Until it is rolled into the UI, do it manually and check the results and take whatever steps you can intuit you should do.) -
  -
13. -
  CVS commit the catalog files. Done
  -
14. -
  If everything went well, reconfigure the new site to take over the role of the old site (/etc/config.tcl and /etc/daemontools/run). Otherwise, bring the old site back up while investigating problems, and then repeat. -
  -
-
Prev Home Next
How to package and release an OpenACS Package Up Index
docs@openacs.org
+
Shut down the production site and put up a notice (no procedure on how to do this yet.)
Start the new site, and upgrade it.
Go to ACS Lang admin page and click "Import All Messages"
Resolve conflicts, if any, on the provided page. +
Back on the admin page, click the export link. If there are conflicts, the messages will be exported anyway and any errors will be shown in the web interface.
Commit the message catalogs to cvs.
From the packages dir, run the acs-lang/bin/check-catalog.sh script. (This checks for keys no longer in use and some other things. Until it is rolled into the UI, do it manually and check the results and take whatever steps you can intuit you should do.) +
CVS commit the catalog files. Done
If everything went well, reconfigure the new site to take over the role of the old site (/etc/config.tcl and /etc/daemontools/run). Otherwise, bring the old site back up while investigating problems, and then repeat. +

Prev	Home	Next
How to package and release an OpenACS Package	Up	Index