), and I got to thinking, why are we relying on files anyway? Why not put the language stuff in the database? I doubt it would be a major resource hog, and we could of course cache it so that we don't have to run queries on every page load. This would make it easier to do what naderman suggested for having a fall back, but instead of including an entire language file to look for one key, we just add an if statement to say that if the language key does not exist in the selected language, check the default language as well. This way you're only loading the keys you need, not each one available.The way I envision in would not require dramatic changes (or any, really) to the way we use the language array (or, better yet, the $user->lang() method), it would just be a different way of storing it and selecting it.
As for language packs, we could even keep the lang file as it is and have an "installer" that processes the $lang array in the files and adds them to the database directly, so we wouldn't need to get rid of the current language files. And because of that, we could allow the admin to select whether to serve language from the files or the database (although then we still need to decide whether to load the default language pack files for a fallback).
So what would need to happen is to add a new table like so (may need some changes, just a rough idea of what we would need):
Code: Select all
CREATE TABLE phpbb_lang_items (
lang_item_id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
lang_iso_id VARCHAR(6) NOT NULL DEFAULT 'en', // this would reference the phpbb_lang table
lang_item_key VARCHAR(255) NOT NULL DEFAULT '',
lang_item_value TEXT NOT NULL, // this is TEXT because varchar is too short in some cases
);
