Keep in mind that this has the benefit of providing UI experts direct access to the labels (even in a monolingual site), so that word choice can be optimized for site usability.
If the approach looks good, you're welcome to do any of the work of course...
NEW TABLES... (with sample data)
1.
create table langs (langid char(4) primary key, name char(204));
insert into langs values('en', 'English');
insert into langs values('pt', 'Portugues');
This will give us more human-readable names of languages, for pulldown menus and such.
The language names should be in the language that they refer to. e.g. "Espanol" rather than "Spanish".
2.
create table labeltext (labelid varchar(32) not null, langid char(4) not null, text text);
insert into labeltext values ('section_news', 'en', 'news');
insert into labeltext values ('section_news', 'pt', 'noticias');
insert into labeltext values ('_meta_section_news', 'en', 'news section');
insert into labeltext values ('_meta_section_news', 'pt', 'regiao das noticias');
3.
another possibility is a labels table:
#create table labels (labelid char(32) primary key, desc_labelid char(32));
insert into labeltext values ('section_news', '_meta_section_news');
Which gives info about each label, such as a description (as a guide on a label editing page).
But so far i don't see a need for the labels table because the descriptions themselves
(metalabels) would also need to be labels (to be language-independent); we can just
enter these meta labels into the labeltext table too, named espcially -- i suggest
"_meta_<labelid>" where <labelid> is the labelid of the label being described.
Although we can enter records for the metalabels in various languages into labeltext,
we shan't want to go beyond that into meta metalabels, etc...
4.
Eventually we'll want to filter the stories by language, so i propose:
create table storylang (sid char(10) not null, langid char(4) not null);
insert into storylang values('2001/9/11/152848/349', 'en');
A story's language is selected on the submit story page.
This is its own table so that it becomes possible for a given story to be marked as being
in more than one language. We could use a multiple select box that defaults to the current
session language.
For a translators' site i'm making, at least, i think it would be good to have bilingual
stories. They would be visible to users of both languages, who would thus generate a
bilingual thread. The author of the original, presumably a bilingual person, could read
all comments together.
Every monolingual story would be hidden from users whose session languages do not match
the story's language.
NEW VARS...
default_lang (default language for the site)
_langid (best left out of the admin interface, unless an override is
desired)
NEW PREFS...
lang (not sure if this is useful, as long as a pulldown appears on every page)
LIBRARY CODE CHANGES...
1.
file: ApacheHandler.pm
location: i put this just above the line:
$S->{UI}->{VARS}->{subtitle} = '';
but it's flexible. it's not much code, but should it tucked into a Language.pm file?
code:
# Language choice
if ($S->{UI}->{VARS}->{_langid}) {
# Administrator override of language choice, possibly in error
} elsif ($S->cgi->param('lang') =~ /^(\w+)$/) {
# Language change via pulldown menu
# Change language for this session
$S->{UI}->{VARS}->{_langid} = $1;
$S->session('lang', $1);
} else {
$S->{UI}->{VARS}->{_langid} =
$S->session('lang') ||
$S->prefs->{lang} || # this pref may not exist
$S->{UI}->{VARS}->{default_lang}; # VAR from admin
}
2.
If we're supporting a userpref for lang choice, then we'll need to have
$S->session('lang', $preferred_lang) called somewhere alongside those subs in Comments/Format.pm.
3.
We'll also want a page to edit the labels, similar to the VAR editing interface.
i haven't done this yet.
4.
We'll also want stories to be language tagged, and the story displayer to hide stories
whose language doesn't match the session language.
NEW BOXES...
1.
boxid: label
title: Labeller
template: empty_box
desc: Returns text in appropriate language, from labeltext table.
content:
my $q_labelid = $S->db->quote($ARGS[0]);
foreach my $lang_var (qw(_langid default_lang)) {
my($rv,$sth) = $S->db_select({
WHAT => 'text',
FROM => 'labeltext',
WHERE => 'langid='. $S->db->quote($S->{UI}->{VARS}->{$lang_var}).
" and labelid=$q_labelid",
});
return $sth->fetchrow_array if ($rv>0);
}
return "$ARGS[1]";
---
Note that the BOX,label can take a second argument -- the default text to return, in case
there is no entry for <labelid> in the labeltext table. This will allow us to start
changing the code even before building (or creating) the labeltext table. We can replace
any <english text> in the html with the call:
"|BOX,label,<labelid>,<english text>|"
where <labelid> is anything to uniquely identify the meaning of the label.
Should we shortcut the BOX,label sytax to just LABEL?
2.
boxid: select_lang
template: empty_box
content:
my $langid = $S->{UI}->{VARS}->{_langid};
my($content);
my($rv,$sth) = $S->db_select({
WHAT => 'langid,name',
FROM => 'langs',
});
return "" unless $rv;
$content .= "<FORM ACTION='/transler/' METHOD='POST'>";
$content .= "<SELECT NAME='lang' SIZE='1' onchange='form.submit();'>";
while (my $data = $sth->fetchrow_hashref) {
my $selected = ($data->{langid} eq $langid)? ' SELECTED' : '';
$content .= "<OPTION VALUE='$data->{langid}'$selected>$data->{name}</OPTION>";
}
$content .= "</SELECT>";
$content .= "<input type='submit' value='switch' /></FORM>";
return $content;
--
This is just a pulldown language selecter to put in the header block or wherever, so that
the user can switch the session language. best left out until the site has a reasonable
amount of non-english labels and it's ready to be considered...
multilingual!
