Possible change in $serendipity['languages'] array
Posted: Wed Mar 26, 2008 11:47 am
Currently $serendipity['languages'] array in serendipity_config.inc.php defines the list of translations to be offered. As the file is overwritten in every update, then that creates problems for those who have made a new translation, but are just testing it on their own site(s) and haven't relesed if for main code (or have any other reason to use appended list of languages).
Solution 1:
Rename $serendipity['languages'] to $serendipity['languages_global'] and create $serendipity['languages_local'] in serendipity_config_local.inc.php
And thereafter add into serendipity_config.inc.php
$serendipity['languages'] = array_merge($serendipity['languages_global'], $serendipity['languages_local']);
Solution 2:
Make the whole language list sql-based. It would be reasonable to use two tables - one for languages and another for the translations of languages names. That would lead to new benefits like the possibility to sort language names correctly in different languages but also a lot more trouble in keeping the whole thing in sync and updated.
In very simplified approach we could use this datastructure (or whatever else is reasonable):
CREATE TABLE languages (
languagecode character varying(5) NOT NULL,
codepage character varying(10) NOT NULL,
systemwide bool
);
CREATE TABLE languages_translation (
id serial NOT NULL,
fk_languages_id character varying(5) NOT NULL,
fk_languages_id2 character varying(5) NOT NULL,
name character varying(75) NOT NULL,
sorting integer
);
fk_languages_id - the translated language name
fk_languages_id2 - the language of the translation
Solution 1:
Rename $serendipity['languages'] to $serendipity['languages_global'] and create $serendipity['languages_local'] in serendipity_config_local.inc.php
And thereafter add into serendipity_config.inc.php
$serendipity['languages'] = array_merge($serendipity['languages_global'], $serendipity['languages_local']);
Solution 2:
Make the whole language list sql-based. It would be reasonable to use two tables - one for languages and another for the translations of languages names. That would lead to new benefits like the possibility to sort language names correctly in different languages but also a lot more trouble in keeping the whole thing in sync and updated.
In very simplified approach we could use this datastructure (or whatever else is reasonable):
CREATE TABLE languages (
languagecode character varying(5) NOT NULL,
codepage character varying(10) NOT NULL,
systemwide bool
);
CREATE TABLE languages_translation (
id serial NOT NULL,
fk_languages_id character varying(5) NOT NULL,
fk_languages_id2 character varying(5) NOT NULL,
name character varying(75) NOT NULL,
sorting integer
);
fk_languages_id - the translated language name
fk_languages_id2 - the language of the translation