21
Mamba
Re: Proposal for a "universal language" system.
  • 2013/1/8 21:39

  • Mamba

  • Moderator

  • Posts: 11366

  • Since: 2004/4/23


Good articles! Thanks for sharing!

There are also couple interesting articles, I've seen recently:

Objects:
http://sheriframadan.com/2012/12/php-oop-objects-under-the-hood/

Arrays:
http://sheriframadan.com/2012/10/a-closer-look-into-php-arrays/

My assumption is that the files for modules won't be too long. And with memory being cheaper every year, maybe it's not a too big issue. Performance, however, might be more critical.
Support XOOPS => DONATE
Use 2.5.10 | Docs | Modules | Bugs

22
redheadedrod
Re: Proposal for a "universal language" system.

Quote:

Mamba wrote:

My assumption is that the files for modules won't be too long. And with memory being cheaper every year, maybe it's not a too big issue. Performance, however, might be more critical.

It MAY matter when getting a host... But like I said... Depends on the total memory used. On my personal server at home I would only be running a couple sites or maybe 10 at most but when renting a server they might frown on you using too much memory but again. It all depends on how much the classes take up. If we are talking 1-3meg of variable usage it shouldn't be a big deal. If we get to where we are talking 20-30 meg then it might be something to consider.

23
irmtfan
Re: Proposal for a "universal language" system.
  • 2013/1/9 5:03

  • irmtfan

  • Module Developer

  • Posts: 3419

  • Since: 2003/12/7


@Mamba:
Quote:

I am still not sure why would we have a different translation for a theme, but from Core perspective, I don't see a problem,

because I have 10 themes in my website and users can change them. It would be better to change more stuff by changing a theme like images/icons and even translation.
Quote:

as long as there is no too much time penalty for checking all the different folders

Im not a performance expert but based on my experiences it will not be the case if you use some methods like define " static $paths;"

Quote:

The above solution is perfect to have a true multilingual solution, regardless of whether we deal with 2 or 50 languages. I hope, we can come up with a seamless design, that would allow this for every future XOOPS module.

I still can not see any mean for implementing a "multilingual database" as described in that white paper.
As i stated before only very few people need more than 3 or 4 languages.(I cannot remember any) also running out of a field space is not always related to number of your languages. I was run out of some fields space even in 1 language in some websites. So i still think we need a "database field size adviser"
For those who want to follow this issue, here is the topic me and Mamba discussed it before:
The best approach for a multi-language XOOPS
@Trabis:

some more questions about your class method.

1- IMO we still need keeping XoopsLocalAbstract class for local functions like substr, ...
so in global/en/en.php we should have.
<?php
class XoopsLocaleEn extends XoopsLocalAbstract{
    const 
EDIT 'Edit';
    const 
DELETE 'Delete';
    const 
HOME 'Home';
    const 
SAVE 'Save';
}


2- what is the difference between a magic call and a regular call of classes.
i mean this:
$x = new XoopsLocale();
$x::DELETE

and this:
XoopsLocale::DELETE

I cannot see any difference.

3- I still dont know if we can have a real GUI translation tool in Xoops with these classes. I mean webmasters could see a page like Tranisfex in Xoops admin for Core/Modules translations, find missing translations easily, save, upload,...



24
bitcero
Re: Proposal for a "universal language" system.
  • 2013/1/9 5:56

  • bitcero

  • Quite a regular

  • Posts: 318

  • Since: 2005/11/26


I think that all options are good, even translations driven by definitions, but my concern is about ease of use.

A system that allows to any person, even if does not know anything about programming, participate actively in translations will be better.

I think that by making the system more abstract will affect the future participation of other kind of contributors. I refer specifically to use of classes for translations.

I think that you know that I've used gettext for all my modules, and this desition is taken for two reasons:

1. Transparency for translate.
2. Ease of use.

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');


and then use this constant wherever I need. Using gettext simply I write a module and forget translations. Translations must be done using a gui editor easily.

Same thing about clases and other methods. This point bring me to point 2.

2. Is very easy for programmers write code and using strings directly and forget about translations. At the same time it's easier for translator simply to use the GUI editor and translate the strings without worrying about code.

Well, It is only an example. The main idea here is that regardless the choosen system, the important is the ease of use for those people that will use it.

IMHO, we need to think on every kind of contributor separately:

1. Translators
2. Developers
3. Designers
4. Final users
5. Other interested people.

I mean, wich tool is much convenient for every type of xoopser?

Sorry for my bad English.

25
Mamba
Re: Proposal for a "universal language" system.
  • 2013/1/9 12:00

  • Mamba

  • Moderator

  • Posts: 11366

  • Since: 2004/4/23


I love the discussion here! We need more of those!

@ Irmtfan:
Quote:
I still can not see any mean for implementing a "multilingual database" as described in that white paper.
As i stated before only very few people need more than 3 or 4 languages.(I cannot remember any)

The question is, how do we want to grow XOOPS in the future? Do we want to focus on individual bloggers or local Websites, or do we want to also focus on companies/businesses? In the increased globalization, there are more and more companies that have to support their customers in different languages. This would be a perfect solution for them. And a good way for our developers to provide such solutions and generate income, so they can make living by developing XOOPS applications.

And if we're only one of the very few who can offer it, or if we do it simpler than anybody else, then this is one more selling point for using XOOPS.

It doesn't matter if we use the Wishcraft solution, or something else - as long as we can offer "multi-lingual" modules out of the box, it is good for XOOPS

But coming back to languages:

@ BitC3R0

Quote:
IMHO, we need to think on every kind of contributor separately:

1. Translators
2. Developers
3. Designers

4. Final users
5. Other interested people.

I totally agree, with the focus on the first three. And we need to also add the performance aspect (speed/memory usage).

I am curious if there is a way to add the Gettext solution to the benchmarks that Trabis did, to see how it measures up to them.
Support XOOPS => DONATE
Use 2.5.10 | Docs | Modules | Bugs

26
trabis
Re: Proposal for a "universal language" system.
  • 2013/1/9 14:09

  • trabis

  • Core Developer

  • Posts: 2269

  • Since: 2006/9/1 1


Quote:
irmtfan wrote: @Mamba: Quote:
I am still not sure why would we have a different translation for a theme, but from Core perspective, I don't see a problem,
because I have 10 themes in my website and users can change them. It would be better to change more stuff by changing a theme like images/icons and even translation. Quote:
as long as there is no too much time penalty for checking all the different folders
Im not a performance expert but based on my experiences it will not be the case if you use some methods like define " static $paths;" Quote:
The above solution is perfect to have a true multilingual solution, regardless of whether we deal with 2 or 50 languages. I hope, we can come up with a seamless design, that would allow this for every future XOOPS module.
I still can not see any mean for implementing a "multilingual database" as described in that white paper. As i stated before only very few people need more than 3 or 4 languages.(I cannot remember any) also running out of a field space is not always related to number of your languages. I was run out of some fields space even in 1 language in some websites. So i still think we need a "database field size adviser" For those who want to follow this issue, here is the topic me and Mamba discussed it before: The best approach for a multi-language XOOPS
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 think core could use a node/content module(should I say extension) responsible to save content. 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). Quote:
@Trabis: some more questions about your class method. 1- IMO we still need keeping XoopsLocalAbstract class for local functions like substr, ... so in global/en/en.php we should have.
<?php
class XoopsLocaleEn extends XoopsLocalAbstract{
    const 
EDIT 'Edit';
    const 
DELETE 'Delete';
    const 
HOME 'Home';
    const 
SAVE 'Save';
}
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! Quote:
2- what is the difference between a magic call and a regular call of classes. i mean this:
$x = new XoopsLocale();
$x::DELETE
and this:
XoopsLocale::DELETE
I cannot see any difference.
There is only one difference, less typing! Btw, It is not a magic call, just the class instantiation. Quote:
3- I still dont know if we can have a real GUI translation tool in Xoops with these classes. I mean webmasters could see a page like Tranisfex in Xoops admin for Core/Modules translations, find missing translations easily, save, upload,...
As I said before, we can use php reflection to get the constants into an array and let the admin do the translation. Then we can recreate the class file with some preg_replace.

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

  • trabis

  • Core Developer

  • Posts: 2269

  • Since: 2006/9/1 1


Quote:

Mamba wrote:
I am curious if there is a way to add the Gettext solution to the benchmarks that Trabis did, to see how it measures up to them.


I used gettext classes from rmcommon and did the benchmark but I was so disappointed that I deleted the files from the package.
I tested getttext with no cache and it took 10 times more then any other method.
I'll give it another try soon with cache to see how it performs.

I think that if we use gettext php extension it would be faster, but not all hosts deliver gettext extension. Most Frameworks use the php gettext (like in rmcommon) because it can be used in any host, but performance is not comparable.

28
Mamba
Re: Proposal for a "universal language" system.
  • 2013/1/9 14:36

  • Mamba

  • Moderator

  • Posts: 11366

  • Since: 2004/4/23


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 think core could use a node/content module(should I say extension) responsible to save content. 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.

Excellent points, Trabis. When we work on XOOPS 2.6.0, it would be good to see how can we improve overall performance of modules (incl. changes to Core, if needed), and provide guidance to module developers on how to take advantage of it. We need to be open to refactoring of existing modules, if it means improved performance, similar to what you did with Publisher by refactoring SmartSection.

Quote:
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, Content Versioning is very important for us! You still have the Versioning class that I've emailed you, right? Having a Version Control "extension" that could be used by all "content" modules, would be awesome.
Support XOOPS => DONATE
Use 2.5.10 | Docs | Modules | Bugs

29
redheadedrod
Re: Proposal for a "universal language" system.

To simplify the translations I still think it would be best if we put the translations into the database and from there can cache them or put them in a file some how so that modules don't need to use a query to pull the translations.

We can then have a module that would allow pretty much anyone to do translations. This module could specifically look for missing translations and build new cache, ini, class files or whatever we end up with and I think it would be MUCH simpler than the current system. It WOULD require a module/extension to administer the translations but to me a user using a module with entry fields is MUCH easier than giving them a file and asking them to fill in the blanks. Or setting up an account on a third party system and manipulating the source files so they fit into the system and hope none of the tags is misspelled or missing outright.


30
redheadedrod
Re: Proposal for a "universal language" system.

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.

Then it can be extended much like the xoops object and handler are now.

It sounds like a Class with all of the strings and any methods would be the best way to do this as long as the memory use doesn't get obscene. You can extend the class easily and as Trabis stated there is a fallback for any missed translations instead of getting the tag name as you get now for a missing entry.

From the articles mentioned by Trabis earlier in this thread it sounds like the memory usage will be minimal and should not be an issue.

And if they are stored as session variables the speed should be significantly faster since they won't have to be reloaded each page load that defines or INI files would be otherwise. And as session variables the class its self wouldn't need to be cached.

Login

Who's Online

199 user(s) are online (95 user(s) are browsing Support Forums)


Members: 0


Guests: 199


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