On 4 Sep 2009, at 03:54, Craig Andrews wrote:
1. What languages should we offer? I'm thinking of storing a 2 letter
ISO-639-1 code with each notice (or NULL, if we don't know). This
means
there is no difference between "English (UK)" and "English (US)"
which I
think is the right way to go. Anyone disagree?
I think it would be nice to accept arbitrary BCP 47 (RFC 4646 & RFC
4647) language tags - to do so would, after all, be "best current
practice". Because there are (for all intents and purposes) an
infinite number of language tags allowed by BCP 47, there is probably
no decent UI to allow people to choose such a tag. So it might be
that the user interface would only use 2 letter codes, but the API
could allow longer codes.
One consideration is that ISO-639-1 doesn't cover all languages.
ISO-639-2 three letter codes offer better coverage. A lot of the
languages not covered by 639-1 are pretty obscure, and we wouldn't
lose much by not supporting them: ancient languages like Hittite,
Aramaic and Gothic; tribal languages like Cherokee and those spoken
in Papua New Guinea; and constructed languages like Blissymbolics and
Klingon. There are a few useful ones in there though - Filipino, for
instance, which has about 90 million speakers, roughly 25 million as
a first language.
6. I'm adding a new database table with this schema:
create table user_language (
user_id integer not null comment 'user understanding the language'
references user (id),
language char(2) not null comment 'language understood'
constraint primary key (user_id, language)
);
This could possibly be exposed in the user's FOAF file:
http://danbri.org/words/2008/03/10/289
--
Toby A Inkster
<mailto:[email protected]>
<http://tobyinkster.co.uk>
_______________________________________________
Laconica-dev mailing list
[email protected]
http://mail.laconi.ca/mailman/listinfo/laconica-dev
