Support Forums - All Posts - XOOPS Web Application System

71

Re: xlanguage will not work with profiles

2013/1/9 19:01
trabis
Core Developer
Posts: 2269
Since: 2006/9/1 1

Seems profile should be saving the constant keys instead of the translations (just like notifications does). That should be an easy fix.

LatinoPoemas

72

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.

LatinoPoemas

73

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.

LatinoPoemas

74

Re: Proposal for a "universal language" system.

2013/1/8 21:12
trabis
Core Developer
Posts: 2269
Since: 2006/9/1 1

Quote:

Mamba wrote:

But the memory consumption surprised me. Defines consume around 20% of what all the others consume.

It bugs me too.
In fact, if I declare the class inside the test script(instead of using a separate file), the memory usage is also low (equal to define) - I guess it has to do on how php stores the constants and how it reports the memory usage.

I've also notice that, when I add more strings, the array method takes more memory per string than the class const. If I have just few lines, array takes less memory. If I add more lines, then the class const wins. I think the class makes use of memory just for the declaration, but that the strings take less memory then arrays.

I did some investigation and I found 2 very interesting articles:
http://imrannazar.com/Memory-Usage-of-Constants-in-PHP

and

http://nikic.github.com/2011/12/12/How-big-are-PHP-arrays-really-Hint-BIG.html

LatinoPoemas

75

Re: Proposal for a "universal language" system.

2013/1/8 13:46
trabis
Core Developer
Posts: 2269
Since: 2006/9/1 1

Quote:

irmtfan wrote: @ Trabis: Ok i understand. you did it just for XoopsLocalePt so for ModuleLocalePt it would be:
<?php include_once dirname(dirname(__FILE__)) . '/en/en.php'; class ModuleLocalePt extends ModuleLocaleEn{ const MODULE_NAME = 'O meu módulo'; }

Correct. Most language should extend the english version. Having pt-PT extending pt-BR is possible but not advised because you force the user to have both the locales available. It is better to just copy all pt-BR class and then do the changes. As for methods, they will be only in the global class (XoopsLocale). The core languages are often delivered by translation team and they also have to create/maintain XoopsLocal(current) class, so I don't see a problem. If a user can edit defines, he can edit constants also. As for the performance, I know it will be better then defines so I'm not concerned. INI are faster and they use less memory because they are compact. My problem is mainly with the auto completion. I think you can imagine yourself opening your translation file(again and again) to see what was the key you where looking for. This happens to me with module configs and I want to avoid having the same problem with languages.

LatinoPoemas

76

Re: Proposal for a "universal language" system.

2013/1/8 0:36
trabis
Core Developer
Posts: 2269
Since: 2006/9/1 1

What about using classes instead of ini files? Here is an example of a class:


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


<?php

include_once dirname(__FILE__) . '/pt.php';

class XoopsLocale extends XoopsLocalePt{

}

Example of usage:


include_once dirname(__FILE__) . '/global/pt/locale.php';



$x = new XoopsLocale();



echo $x::DELETE;

echo '<br>';

echo $x::EDIT;

echo '<br>';

echo $x::SAVE;

echo '<br>';

This is 3 times faster then defines and just a little bit slower then ini files. On the upper side, we gain autocompletion in file editors. Autocompletion is something we do have with defines and that we will miss if using ini. Since it is class based, languages can extend other languages. pt-PT can extend pt-BR, etc If a constant is missing, the parent class will provide the constant. This requires 2 files per module. One containing the translations, and other just for type casting(just extends the class that has the translations). Translations can be accessed by XoopsLocale::STRING_TO_TRANSLATE; PublisherLocale::STRING_TO_TRANSLATE; NewsLocale::STRING_TO_TRANSLATE; No need to prefix strings with _MI_MODULENAME_(STRING_TO_TRANSLATE) :) We can also use this classes to hold the current XoopsLocal methods. The same class provides translations(via const) and methods for localization like substr, date, formattimestamp, etc Updating translations is simple. Using the editor 'Structure view' you can see what constants are in grey and just update them. Even if a constant is missing for your language, it will fallback to the english version delivered by the module/core(or whatever class it extends). You can also use a diff tool and merge easily. If we need to parse the classes to insert the translations in db we can use php Reflection. One thing you cannot do: Force a string to be translated in another language. If the PT classes are loaded, you cannot force a module/core to display a string in EN. You cannot have two XoopsLocale loaded or two PublisherLocale loaded at the same time! A 'class already exists' will pop out. Anyway, even if using ini files would allow it, it would not be advised for performance reasons. I have prepared a package with some examples. There is a folder called memusage where you can compare performace of ini vs array vd define vs class.

LatinoPoemas

77

Re: Proposal for a "universal language" system.

2013/1/6 21:45
trabis
Core Developer
Posts: 2269
Since: 2006/9/1 1

With the move to INI files and the extra parsing that will be required for each file, we will have to add a cache layer. We will be fetching the translations from the cache, not from the files. Between this cache layer and the file layer we can/should add a database layer.
As you propose, we can fetch the files, and save entries on db. This will allow the admin to edit the db entries and get assistance on translating entries not yet translated. This assistant can propose translations based on similar entries.
As this entries are saved/updated, cache files are generated. It is this cache files that we will be loaded when a loadLanguage() method is triggered.

LatinoPoemas

78

Re: problem with xoops path

2013/1/6 18:36
trabis
Core Developer
Posts: 2269
Since: 2006/9/1 1

Please make sure you have all open ( closed with a )
If you could post the entire mainfile it would be easier to spot the error.

LatinoPoemas

79

Re: XOOPS 2.6 Internationalization/Local support

2013/1/6 17:25
trabis
Core Developer
Posts: 2269
Since: 2006/9/1 1

Quote:

DCrussader wrote:
From bad to worst (Nuke to WP), let's make it like Drupal, it's a solid-rock CMS which no one use from ages, the only CMS which uses NODE instead of Article, well 2nd using Weight instead of Ordering, Taxonomy Term for Sub-category, and adding GNU Gettext.

I think you misunderstood me. I'm not looking after WP way of doing translations. But I think the standards they propose can be applied to Xoops.

Quote:

X-1.0.zip downloaded %1s (one download)
X-1.0.zip downloaded %2s (many downloads)

Seems you agree with using placeholders.

Quote:

2nd point - no idea what for will be used as language files, INI, POT, PHP or something else ? How much alphas will go out ?

It does not depend only on me. I'm thinking seriously on using INI files and have the code using it on alpha3. Perhaps the translate class and some demos can be release on alpha2, for review.

Quote:

3rd.....
Several different threads are opened for 2.6 without mentioning simple task tree:

I find organization a very complex subject. The core team is working very fine without using 'simple' tasks. We have pending simple tasks on sourceforge for years now.

Quote:

Quote:

- use html2pdf in extension "pdf" (http://html2pdf.fr/en/default)

How the decision was taken for this ? XOOPS was "community driven", where was the Poll regarding all alternatives ? I think something like this was used in J! 1.0 and removed by own class in 2.5, so the users can make PDF of any content type from the sites in Cyrillic.

htm2pdf contains the tcpdf library so the core team thought it would be a good addition. We can't discuss every subject with the community. If this library does not work on Cyrillic sites we will definitely look for other solutions. We are on alpha stage, we did not test this library on all contexts and we do expect users to report problems.

Quote:

Quote:

- In order to easily add content "out of the box" .

This means nothing - content like the default option in Baned CMS ? Wow if is this, amazing, just amazing....

I can't tell if you are being sarcastic. Since 'page' module is delivered with the core package it will allows users to publish pages without having to look around for content modules.

Quote:

Quote:

- This system allow to create all kind of menus.

Simple Menu Manager or something like Solo Menu module ?

Something like Solo Menu module. It is a refactoring of Mymenus module which was based on the multimenus module by Solo.

Quote:

File Manager/Image Manager ? Maybe in Alpha 5 on random pick without votes ?
Content/Blocks editor - SC, tinyMCE (yack), CK, default used in XOOPS 2.5 ?

Image manager will be just a "move from core to module". We will be looking at features at latter stages. Being modules/extensions, other developers can deliver their own versions which can latter be used as the official module.
I don't know which editor we will be using has default.

Quote:

Alpha 3 looks like Beta 1
And Final 2.6.0 around Christmas 2013 or Q2 of 2014.... (but better late, then never )

We are aiming for latter dates so we don't disappoint the community. I hope we can do this faster then the roadmap suggests.

Quote:

Won't mention my favorite - Sign up/in, Weight and a lot of other termins not used anywhere else except in Drupal/XOOPS 2.5/WP, which making system not only "non-user friendly" but also not understandable...

I think we will be able to deliver a more user/developer/translator/designer friendly XOOPS. And by 'we' I mean users/developers/translators/designers.

LatinoPoemas

80

Re: XOOPS 2.6 Internationalization/Local support

2013/1/5 19:12
trabis
Core Developer
Posts: 2269
Since: 2006/9/1 1

Quote:

irmtfan wrote: Hi Trabis Im glad that you read this topic. Among all subjects in this topic the issue you raised ("Formatting in PHP Definitions") is the least important one. IMO all html formatting should be moved to templates/css/themes. so i think we all are agreed this should not be allowed anymore:
define("_MD_SUSPEND_TEXT","User %s is suspended for %d days due to:<br />[quote]%s[/quote]<br /><br />The suspension is valid till %s");

Sorry for raising this issue, but I agree with the others, just not this one. I agree with the above example. Html formatting should be done on templates/css. Quote:

I think the only advantage of using sprintf is its formatting capability? and when we dont want to use this advantage why we still should use this. also concatenations are much faster than sprintf? (about 150%) am i wrong?http://micro-optimization.com/string-concatenation-with-double-quotes-vs-sprintf and this:http://r.je/sprintf.html

The above examples do not use keys and are not translatable(only directly in file). They do not call any function to do a translation. $str = 'Hi ' . $name . ', you last logged in on ' . $date; They are faster but do not have appliance in a translatable project. Now, with translate calls, would this be good for you? $str = _('HI') . $name . ', ' . _('YOU_LAST_LOGGED_IN_ON') . $date; Aren't we forcing translators to use a rule established by the code developer? What if translator wants to greet the user after giving the logged in date? Look at the absurd: $str = _('HI') . $name . _('COLON') . _('SPACE') . _('YOU') . _('SPACE') . _('LAST')..... We should translate expressions, not single words. Concatenations are a work for translators. Imagine if google translated word by word not regarding the context. Also notice that every time we call a function we are impacting performance. Using concatenations will produce more calls, more time spent. Quote:

Also there is not that WP standard in XOOPS to have %1$s, %2$s, %3$s,... in definitions.

We can change that!

LatinoPoemas

Stats
Goal:	$100.00
Due Date:	May 31
Gross Amount:	$0.00
Net Balance:	$0.00
Left to go:	$100.00

Forum Index

Re: xlanguage will not work with profiles

Re: Proposal for a "universal language" system.

Re: Proposal for a "universal language" system.

Re: Proposal for a "universal language" system.

Re: Proposal for a "universal language" system.

Re: Proposal for a "universal language" system.

Re: Proposal for a "universal language" system.

Re: problem with xoops path

Re: XOOPS 2.6 Internationalization/Local support

Re: XOOPS 2.6 Internationalization/Local support

Login

Search

Recent Posts

Re: Rebuilding and Updating a 20 years old Xoops Website from 2.0.18? to 2.5.11

Rebuilding and Updating a 20 years old Xoops Website from 2.0.18? to 2.5.11

Re: NewBB v 5.1.0 b 6

Re: NewBB v 5.1.0 b 6

NewBB v 5.1.0 b 6

Re: XOOPS 2.5.11 search user is not working

Re: oledrion

Re: oledrion

Re: oledrion

Re: oledrion

Who's Online

Donat-O-Meter

Latest GitHub Commits

{{ record.sha.slice(0, 7) }} - {{ record.commit.message | truncate }}