Quote:
The wishcraft solution is good for changing content and not just the translation files. It is just like adding categories, where the categories are the languages themselves.
I know how this method works but i think it is a useless extra work for multilingual purposes. It needs changing all current modules database structure and having more queries at the end while we already dont have problem with current modules.
Quote:
Newbb already uses a separate table just to hold the text content of a post, it would be no different to use the node/content table instead. This is good for performance because in most cases, we just get the title (blocks, lists, etc) . Using select * is not effective when the body/text comes along with it. This node/content module could also manage different versions of the same itemid, not just for language proposes, but also for versioning (like some article modules have).
Yes. but if you do it for languages in most cases you should get the content from that node (eg: "en") even for 1 language websites. i consider it as an extra work.
Also using nodes will not always good based on my recent experiences with newbb sometimes it would a headache to find a good solution to get data.
eg look at this query:
SELECT p.*, t.* FROM bb_posts AS p LEFT JOIN bb_posts_text AS t ON t.post_id = p.post_id LEFT JOIN bb_reads_topic AS r ON r.read_item = p.topic_id AND r.uid = 1 WHERE (p.forum_id IN (1) AND p.uid = '1' AND p.approved = '1' AND (p.post_id > r.`post_id` OR r.read_id IS NULL)) ORDER BY p.post_id DESC LIMIT 0, 10
and also this one:
SELECT t.*, p.post_time as last_post_time, p.poster_name as last_poster_name, p.icon, p.post_id, p.uid, p.post_karma, p.require_reply, pt.post_text FROM bb_topics t LEFT JOIN bb_posts p ON p.post_id = t.topic_last_post_id LEFT JOIN bb_reads_topic r ON r.read_item = t.topic_id AND r.uid = 1 LEFT JOIN bb_posts_text pt ON pt.post_id = t.topic_last_post_id WHERE 1 = 1 AND (r.read_id IS NULL OR r.post_id < t.topic_last_post_id) AND t.forum_id = 1 AND t.approved = 1 ORDER BY t.topic_last_post_id DESC LIMIT 0, 20
The above is for getting the unreaded items (here posts and topics) to find the "new posts/unreaded topics". it was unsolved for 7 years and one reason was there was 3/4 tables and many fields. so it was complicated to find the correct SQL Syntax for
module developer to 1- do the job and 2- good performance. (I first wrote a sql command that makes the page loaded after 20 seconds
)
So while im not against of using these kind of nodes i think you should consider easy developing and good performance too.
Quote:
I could agree, but php does not allow multiple 'extend'. That would work for en, but if I use it for pt, then I could not extend the en class, I would loose the fallback feature!
I thought it could be extend like this in english:
<?php
class XoopsLocaleEn extends XoopsLocalAbstract{
const EDIT = 'Edit';
const DELETE = 'Delete';
const HOME = 'Home';
const SAVE = 'Save';
}
then this in local language:
<?php
include_once dirname(dirname(__FILE__)) . '/en/en.php';
class XoopsLocalePt extends XoopsLocaleEn {
const EDIT = 'Editar';
const DELETE = 'Apagar';
const HOME = 'Início';
//const SAVE = 'Salvar';
}
and finally followed by this one:
<?php
include_once dirname(__FILE__) . '/pt.php';
class XoopsLocale extends XoopsLocalePt{
}