CVS log for loncom/localize/lonlocal.pm

Up to [LON-CAPA] / loncom / localize

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

- Bug 6971 Individual user preference for Time Zone.

- Typo in documentation

- Documentation changes.
  - search.cpan.org was retired in 2018
  - eliminate pod2man warnings about =item outside of an =over.
  - remove some trailing white space.

fixed bug 6782, and escaped most localized messages used in Javascript blocks to make sure bugs like that do not happen again

- Coding style: keys()

Update Documentation: Don't loose the idea how to spell loser ;-)

- No longer request domain config for domain: "public".
  Suppress "get_dom failed - no homeserver and/or domain" logspam in lonnet.log.

- New arg for: &get_language_handle() - can supply the language code for
  the language to use.
- New routine: choose_language() - used when a script is run from command
  line, and user is prompted to choose a language (by entering two-letter
  language code).

- Customization for GCI_3.
  - language codes are three characters or less.

- Customization for GCI_3.
  - Suport for multiple Concept Inventories.

- Browser detection needs to set browser.unicode for IE if charset for page is UTF-8
  and there is a possibility TTH will be used.

- Backport 1.59 (part).

- Customization for GCI_3 (same change as 1.60.2.1 for GCI_2).
    - gci and gct "languages" provide custom phrases for gci and gcitest domains respectively.

- Customization for GCI.
- gci and gct "languages" provide custom phrases for gci and gcitest domains respectively.

- Better choice of default domain for multi-domain servers.

- Customization for GCI_1.

- lonlocal.pm for GCI_1 updated to 2.8.X
- Backport 1.52, 1.53.

- reverted changes made in lonlocal.pm 1.58 and lonwhatsnew.pm 1.92
- the root cause for slow performance in lonwhatsnew while looking up received mails
  was found in DateTime::TimeZone's methods for looking up the 'local' timezone:
  [SOURCE: http://search.cpan.org/~drolsky/DateTime-TimeZone-0.90/lib/DateTime/TimeZone/Local/Unix.pm]
  "This class tries the following methods of determining the local time zone:

    * $ENV{TZ}
      It checks $ENV{TZ} for a valid time zone name.

    * /etc/localtime
      If this file is a symlink to an Olson database time zone file (usually in /usr/share/zoneinfo) then
      it uses the target file's path name to determine the time zone name. For example, if the path is
      /usr/share/zoneinfo/America/Chicago, the time zone is "America/Chicago".

      Some systems just copy the relevant file to /etc/localtime instead of making a symlink. In this case,
      we look in /usr/share/zoneinfo for a file that has the same size and content as /etc/localtime to
      determine the local time zone.[...]"

  On our CentOS server /etc/localtime happens to be a copy and this causes TimeZone to do an expensive
  search through the files in /usr/share/zoneinfo (everytime locallocaltime needs the 'local' timezone).
  To prevent TimeZone from doing this search we store the timezone found after the first run in $ENV{TZ}.
  Future calls of locallocaltime will be significantly improved in performance.
  This affects every module that calls locallocaltime (not only lonwhatsnew.pm).

Locallocaltime-Function SpeedUp Hack

Another attempt at an &mt-cache

Character encoding UTF-8 needed for the whole LON-CAPA system
Revoke changes rev. 1.33 and rev. 1.34
(Set browser to ISO-8859-1 encoding, if client OS is MS Windows and browser type is Internet Explorer)

Current tests can _not_ confirm a difference
(tested with LON-CAPA CVS head (2009-03-20 19:00 GMT+01),
Windows 2000 SP4 and MSIE 6.0 / Windows XP Prof. SP3 and MSIE 7.0)

Details: Bugzilla 5702 vs. 2189 and 4067

Deactivated new cache functionality for &mt
which was introduced in revision 1.54
due to missing/incorrect functionality:
  - Returned empty value instead of translation in some cases
  - Didn't respect user pref language changes
  - Didn't respect course language

Localize Cache: Improvement in the mt function in lonlocal.pm for testing (much faster, final version in the next few days)

- Backport 1.53.

- When course activity log data are stored in $cnum_$cdom_activity tables, timestamps are stored using lonmysql::sqltime() which employs the server localtime.
- Student Activity displayed with trackstudent needs to have these timestamps converted to the time zone set for the course.
   - &server_timezone_handler() in lond retrieves server time zone from /etc/sysconfig/clock or /etc/timezone depending on distro.
   - &get_server_timezone() in lonnet.pm gets server time zone from course's homeserver.
   - &gettimezone() in lonlocal.pm can now take a timezone as an argument.
       - will validate it, and return it if valid, 'local' otherwise
   - &convert_timezone() in lontrackstudent.pm converts timestamps prior to display, and includes course time zone.

- Backport 1.52.

- Moving &preferred_languages() and &get_genlanguages() from loncommon.pm to lonlocal.pm, so they cn be available in cases where lonlocal.pm is used but loncommon.pm is not.

POD changes

Backport 1.50.

- Retrieve default timezone for domain, in other contexts besides courses.

Bugs: 5792 and 5798.
- Uses DateTime, DateTime::Locale, DateTime::Locale::Catalog.
- Disposition of events in calendar display now consistent with current time zone.
- Timezone in effect is displayed in Calendar header line.
- First day of week determined from date localization in effect.
- Extra empty row eliminated from end of calendar.

- Default date localization can be set for domain from Default auth/language/timezone section of Domain Configuration.
- Date localization can also be set for a specific course via "Set Course environement".
- When in course context, course-specific date localization applies (if set), otherwise default date localization of domain of course (if set).  In other contexts, date localization of domain of user (if set) applies.

- Currently date localization is only used to determine starting day of the week (for building calendar display).  Future uses might consider date order/format for display of dates.

- &timehash() and &maketime() routines in loncommon.pm modified to use time zones.
- &nextday() routine in lonannounce.pm modified to correctly identify next day.
- &getdatelocale() routine added to lonlocal.pm to retrieve date locale object.

- Bug 5786. Language used for text wrapped around body of message in notification e-mail should correspond to language preference of recipient determined in order: user pref, domain default), unless message is sent in course content, and a language is defined for course (use course langage in this case).
lonmsg.pm - &user_lang() used to get a language hadler for recipient.
          - Translation of text uses &mt_user() instead of &mt().

lonlocal.pm - &mt_user() added (exported). Calls maketext, but takes language handler as firrst arg.

loncommon.pm - &get_genlanguages() added - functionality to turn en-ca into en-ca,en and also to remove duplicates from @preferred_languages - moved from &preferred_languages() to a separate subroutine so it is more widely available.

Bug 5638.
 - Sanity checking of $thistime passed to locallocaltime(), before calling DateTime->from_epoch() to prevent ISE.

- Check the retrieved timezone is valid for the version of DateTime() on the server.
  If not default to local.

Bug 5722.
A default timezone can be set for a domain via the Domain Configuration menu.  This will be the timezone in effect in courses in the domain for which a course-specific timezone has not been set in the course environment.

- maketext() in Locale::Maketext 1.12 (used with perl 5.10) includes:
added line - Carp::confess('No handle/phrase') unless (defined($handle) && defined($phrase));
 -so don't call maketext() if there's no text to localize.

Bug #5609: In America, the week starts with Sunday. But elsewhere ...

- add ability to set the timezone of a course

- need to protect user title when being &mt() BUG#4985

- showing the epoch as a real date only makes sense to programmers, let's try never instead

- handling timezones correctly

- moving handler into seperate file so lonlocal.pm can be used in CGI

- remove dead code

- deathe the Apache::File

Display timezone for absolute dates and times.

- BUG#4067, set IE on windows to ISO if nothing more specfic wants something else.

- tth, UTF-8 and IE don't get along

- if that language doesn't specify the encoding pick utf-8 by default

- &mt() would return an array into scalar context, needs to return a scalar in those cases
- printout.pl now has the headers, and set charset properly
- lonlocal works in a CGI context (but of course it will be slower since the language handle isn't persitent)
- loncommon::content_type works in a CGI context

Might be a good idea to not submit the debugging code ...

Bug #2471: our localization scheme only worked because get_language_handle
was usually called when $ENV{'HTTP_ACCEPT_LANGUAGE'} was not yet set. That
was not the case when an internal redirect had happened.

Saving my work on trying to get the languages right after re-init, etc.
Currently totally dysfunctional.

Internationalize publisher.html

Minoru had a better idea on how to show translators where material appears
on the screen.

Move <mt>-tag into separate module to avoid module-dependency vicious cycle.

Saving my work: internationalize static html files.

Internationalize.

Commit &mtn since lonhelper is blowing up left and right.

Return 'en' as language if $lh is not defined.

- stop blowing up when $lh ain't there

Internationalization, and in particular, lonlocal:locallocaltime and
Japanese dates.

Bug #2248: enable locale-dependent rendering of dates.

Add a normalization function to lonlocal.

Looks like setlocale is causing all sorts of trouble, probably broken.

It would be too nice if the locale names had anything to do with the
language codes, or the charset, in a predictable way ... but they do
not.

The next adventure: formatting of numbers and times, definition of what
is a \w-character, etc.

Remove useless code.

- I keep getting crashes without these checks on $lh
   I haven't yet tracked down who was causing these.
- $r->content_laguages([&current_language]);
     keeps throwing:
 [Mon Sep 22 14:16:50 2003] [error] [client 127.0.0.1] val is not of type APR::ArrayHeader at /home/httpd/lib/perl/Apache/lonlocal.pm line 128.
   I am working around it by ignoring it for now

Grrr ... it would be nice if $lh->language would spit out the currently
used language, but instead, it does look at the browser ... need to encode
language into translator file.

Add Gerd's I18N email to the POD documentation of lonlocal, for
preparation for entry into the developer's manual.

Setting content language in headers.

Saving my work.

Store character encoding in lexicon.

Get current language directly from lonlocal

Oops.

Better German lexicon, work on translator interface.

Continued work on Maketext
* can now set language preferences
* adv users can set "translator" language, and access little script to
enter translations for phrases covered by &mt

Continued work on localization.

Translation files go into

loncom/localize/localize

as

de.pm
pt.pm

etc. Rest should be automagic.

Start of localization work with Locale::Maketext under the hood.

Usage (eventually):

use Apache::lonlocal;
...
$r->print( ... &mt('Stuff') ... );