31
trabis
Re: Proposal for a "universal language" system.
  • 2013/1/9 20:56

  • trabis

  • Core Developer

  • Posts: 2269

  • Since: 2006/9/1 1


Here is another package with 3 extra memusage/speed tests.
One is for php gettext used in rmcommon. (called gettext.php)
Another is for php gettext used in Sabai Framework(from onokazu) it uses a Pear class. (called sabai_gettext.php)
Another is for php extension gettext. (called ext_gettext.php)
I was not able to get the extension doing the translation. Perhaps somebody can fix it for me. Anyway, you can get an idea for the performance.

32
trabis
Re: Proposal for a "universal language" system.
  • 2013/1/9 21:04

  • trabis

  • Core Developer

  • Posts: 2269

  • Since: 2006/9/1 1


Quote:

redheadedrod wrote:
I am assuming the INI files we are talking about are like the ones mentioned in this article:
http://devilsworkshop.org/tutorial/parsing-ini-files-using-php/12926/

Unless you can load a main INI file then over write the contents of memory with another INI file I think Trabis is on the right track with class constants.

When you parse the ini file you get an array. You can parse 2 ini files and then merge the arrays.

33
trabis
Re: Proposal for a "universal language" system.
  • 2013/1/9 21:33

  • trabis

  • Core Developer

  • Posts: 2269

  • Since: 2006/9/1 1


Quote:

BitC3R0 wrote:
What do I mean?

1. For me, to write modules using strings with:

__('Text to be translated')


Is more transparent than:

define('CONSTANT','Text to be translated');



There are some downsides I can think of:
1 - performance is not good or as good as other methods.
2 - you may have to type the same loooooooooooong string in several scripts. If you type the string a little differently you need new translation so you start copy/pasting things around. With class method you type only once, then autocomplete can do the task for you.
3 - Because it does not use short keys, the translation itself becomes the key ( a long key). If I need to insert a config name or something else that needs translation in the database, I will need more space for the correspondent db field. For example, storing translation for a config description may become a problem (think xoops_version.php, notifications, templates, blocks, etc). A system using short keys, in my opinion, is more appropriated.

34
Mamba
Re: Proposal for a "universal language" system.
  • 2013/1/9 21:47

  • Mamba

  • Moderator

  • Posts: 11366

  • Since: 2004/4/23


Trabis, this is what I got when I run all of them, with Array result as the baseline at 100%:

Resized Image


Resized Image


The Gettext were totally off the chart with speed, so I had to cut off the chart).

The Ext-Gettext had some issues with the memory - it was way too low.
Support XOOPS => DONATE
Use 2.5.10 | Docs | Modules | Bugs

35
irmtfan
Re: Proposal for a "universal language" system.
  • 2013/1/11 4:06

  • irmtfan

  • Module Developer

  • Posts: 3419

  • Since: 2003/12/7


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 010

and also this one:
SELECT t.*, p.post_time as last_post_timep.poster_name as last_poster_namep.iconp.post_idp.uidp.post_karmap.require_replypt.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 AND (r.read_id IS NULL OR r.post_id t.topic_last_post_id) AND t.forum_id AND t.approved 1 ORDER BY t.topic_last_post_id DESC LIMIT 020


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{
}





36
trabis
Re: Proposal for a "universal language" system.
  • 2013/1/11 7:52

  • trabis

  • Core Developer

  • Posts: 2269

  • Since: 2006/9/1 1


Quote:
irmtfan wrote: 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';
}
But as you can see, we are extending XoopsLocalAbstract En version. How can I extend the Pt XoopsLocalAbstract since I'm already extending XoopsLocaleEn?

37
irmtfan
Re: Proposal for a "universal language" system.
  • 2013/1/11 10:19

  • irmtfan

  • Module Developer

  • Posts: 3419

  • Since: 2003/12/7


Quote:

How can I extend the Pt XoopsLocalAbstract since I'm already extending XoopsLocaleEn?

We didnt have Pt XoopsLocalAbstract in xoops 2.5.5 and we dont need it. we already have Xooplocale class in locale.php so for local parties we just write our local functions.

eg:
<?php
include_once dirname(__FILE__) . '/pt.php';
class 
XoopsLocale extends XoopsLocalePt{

    static function 
getTimeFormatDesc()
    {
        return 
_TIMEFORMAT_DESC_8;
    }

}


or for persian numbers i can add local number format.
<?php
include_once dirname(__FILE__) . '/fa.php';
class 
XoopsLocale extends XoopsLocaleFa{

     static function 
number_format($number)
    {
        if (
_JDF_USE_PERSIANNUM){
            return 
Convertnumber2farsi($number);
        } else {
            return 
$number;
        }
    }
}


I cannot see any problem. local functions in locale.php and translations in fa.php



38
Mamba
Re: Proposal for a "universal language" system.
  • 2013/1/11 11:13

  • Mamba

  • Moderator

  • Posts: 11366

  • Since: 2004/4/23


Quote:
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.

I am not for one particular method of achieving it. If there is a better way, let's do it that way.

The goal for us is to make XOOPS the "Best and easiest to use Multi-lingual CMS". The globalization is more and more happening, and more and more people and companies want to have a multi-lingual Websites that are easy to create, use, and maintain.

Quote:
So while im not against of using these kind of nodes i think you should consider easy developing and good performance too.

Absolutely! That goes without saying!
Support XOOPS => DONATE
Use 2.5.10 | Docs | Modules | Bugs

39
trabis
Re: Proposal for a "universal language" system.
  • 2013/1/11 13:29

  • trabis

  • Core Developer

  • Posts: 2269

  • Since: 2006/9/1 1


Quote:

irmtfan wrote:
I cannot see any problem. local functions in locale.php and translations in fa.php


Ah, I got it but... let me go back a little.
My first propose was 2 files per language:
1 - One file just for type casting (ex: XoopsLocale or ModuleLocale)
2 - One file to hold translations and methods (Ex: XoopsLocaleEn or ModuleLocaleEn)

Then I though you proposed 3 files per language
1 - One file for type casting
2 - One file for translations
3 - One file for methods

What you did propose however was using 2 files:
1 - One file for type casting and methods
2 - One file for translations

The only problem I see with your propose is that a pt_PT/XoopsLocale cannot extend a pt_BR/XoopsLocale and it would have to implement the methods with copy/paste. In my propose this could be done since the translation classes can extend other translation classes(they have different names).

Personally I think your propose is good/better. I think that all languages should extend just the english version. Full translations should be provided for pt_PT and for pt_BR and same goes for methods. You agree?

40
irmtfan
Re: Proposal for a "universal language" system.
  • 2013/1/12 5:59

  • irmtfan

  • Module Developer

  • Posts: 3419

  • Since: 2003/12/7


Quote:

What you did propose however was using 2 files:
1 - One file for type casting and methods
2 - One file for translations

I just thought it would be good standard to separate translations from functions (I should save the file contain translation in utf-8 without BOM but i can save the file contain functions in any standard format) but we can wrote translations and methods in fa.php as you proposed.

Quote:

The only problem I see with your propose is that a pt_PT/XoopsLocale cannot extend a pt_BR/XoopsLocale

yes. you are right.
I think it is possible with your proposal.(if we dont follow any standard and let users to do what they want)

Just i dont know what will happen on performance when we extend such a number of classes?
here:
1- en extends XoopsLocalAbstract
2- pt_BR extends en (translation + functions)
3- pt_PT extends pt_BR (translation + functions)
4- XoopsLocale extends pt_PT

about multilingual XOOPS:
Our only problem with the old system is the limited space in the field and we have this issue only in "title fields" not "text fields"

eg: i never run out of space in a news body/post body. i always have issues with news titles/ forum names/ categories,...

So I think nodes for text fields will not solve anything regarding multilingual unless you want to implement nodes for "any content" which i think is bad for performance and developing.

Login

Who's Online

244 user(s) are online (166 user(s) are browsing Support Forums)


Members: 0


Guests: 244


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Mar 31
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits