11
irmtfan
Re: XOOPS 2.6 Internationalization/Local support
  • 2012/7/12 1:50

  • irmtfan

  • Module Developer

  • Posts: 3419

  • Since: 2003/12/7


redheadedrod:
I read your post almost 3 times but i still fear i could not understand it totally.
Quote:

Storing dates and times in the standard database format allows you to perform queries based on those "standardized" dates.

Quote:

Internally the date/time is normally stored as so many seconds since a certain time/date but is seldom accessed directly in that manner.


do you mean there is just one unique standard database format as i mentioned before as "int"?
so i can show you my prev example in more detailed manner:

In local persian:
Database int("2012-07-11")----formatTimestamp---> jdate local---> "1391-04-21" --> userside
In general (english):

Database int("2012-07-11")---formatTimestamp---> userside

Quote:

Sounds like to "globalize" we just need a way to convert back and forth between different calendar types.

please as i stated in the first post do not conflict between "localization/internationalization" and "globalization". They are not in contrary with each other nor have any relations. they are completely different concepts. you can localize without globalize or globalize without localize or you can do both or none of them.
[off topic]
globalization examples in xoops: using google recaptcha, sfs, xortify cloud, relations with social networks like twitter, facebook and ...
[/off topic]

Quote:

do it in a manner that we can use generic statements to store or retrieve the data that would translate for the different calendars.


I already show you how we can retrieve using current xoops local function "formatTimestamp". Also I can show you the local way of storing (the backward way)

eg using the current core functions (userTimeToServerTime, strtotime):
In local persian:
Database int( "2012-07-11")<-- userTimeToServerTime <--- strtotime---- "2012-07-11"<--- inputTimeToGregorian local <--- "1391-04-21" <--- userside
In general (english):
Database int("2012-07-11")<-- userTimeToServerTime <--- strtotime---- "2012-07-11" <--- userside

Quote:

By this I mean you could set your site to use a calendar and all the display and entry of the site would use the preferred calendar but it would still store them in the database in the format the database desires

excellent, the best explanation of date/time localization.

Quote:

but by using these core routines that take care of the conversion for you they do the "dirty" work


No. not at all. the above using formatTimestamp function to localize output date/time is the cleanest way i can imagine.
no core file is hacked. the function is just located in language/persian/locale.php

same we can do for input date/time.
currently strtotime is not localized. you can find some examples in the core files like this one in modules/system/admin/mailusers/main.php
$time strtotime(trim($_POST['mail_lastlog_max']));
                    if ( 
$time ) {
                        
$criteria[] = "last_login < $time";

core developers should localize "strtotime" or define a new xoops function for input date/time from scratch.

see this feature request:
http://sourceforge.net/tracker/?func=detail&aid=3537303&group_id=41586&atid=430843

Quote:

Then promote the use of these core routines to module developers.

rather than that IMO we should force them. eg: now if they dont use "formatTimestamp" it will considered as a bug.

Mamba wrote in another topic:
Quote:

In the near future, we'll need to convert News from fpdf to tcpdf, so all modules are consistently using tcpdf, and we can provide tcpdf as part of XOOPS library.

excellent approach. but tcpdf is above 10MB.

12
irmtfan
Re: XOOPS 2.6 Internationalization/Local support
  • 2012/7/12 5:58

  • irmtfan

  • Module Developer

  • Posts: 3419

  • Since: 2003/12/7


Quote:

Then promote the use of these core routines to module developers.

I like to write about this more and i will provide you detailed examples that how to promote.

Many localization matters are already available inn core but developers/desginers never used them.
for eample please promote "image localization" for xoops theme designers.
we should encourage xoops theme designers to use local lang smarty code for images. (all images would be better but for images contain some characters would be nessesary)
currently everything is localized in themes and multi-language is implemented in official english themes released in xoops 2.5.5 except images.
eg: in xoops255/htdocs/themes/default/theme.html

<{$xoops_sitename}>

should be changed to:
1st way:
<{$xoops_sitename}>
2nd way:
<{$xoops_sitename}>

then the image should be renamed like below:
1st way:
xoops-logo.en.png

2nd way:
img/en/xoops-logo.png

please choose the preferred/best way for doing that. Then it should be promoted.

Quote:

timgno wrote:
My modest support is available


Yes and i support it.
Quote:

2- core developers should add "JQuery UI datepicker" first then all developers can use that in their codes.


just please consider localization. ability for including js files in different languages.
could you implement that and show us the result?

13
Mamba
Re: XOOPS 2.6 Internationalization/Local support
  • 2012/7/12 6:45

  • Mamba

  • Moderator

  • Posts: 11409

  • Since: 2004/4/23


Quote:
excellent approach. but tcpdf is above 10MB.

1) Once you download tcpdf library, you don't have to do it the second time. Right now many modules are having it internally, so if you have 3 modules, you have to download 30 MB

2) But I think that PDF should be done as "optional", i.e. if the users selects PDF option in Preferences, the module should check if tcpdf library exist, and if not, then it should tell the user to download it. This will be good for people who don't care about having PDF in a module...
Support XOOPS => DONATE
Use 2.5.11 | Docs | Modules | Bugs

14
irmtfan
Re: XOOPS 2.6 Internationalization/Local support
  • 2012/7/14 9:32

  • irmtfan

  • Module Developer

  • Posts: 3419

  • Since: 2003/12/7


I had a conversation with Voltan in xoops persian local support site and he mentioned that the main size of tcpdf is its "fonts" folder.
So the best way would be including tcpdf with some necessary fonts in the core and make some localization enhancement for others to add fonts in their local.
eg: language/LANG/fonts

IMO xoops need a "font manager" and "mimetype manager" as plugins in system module .You can see many module have internal functions/tables/scripts for mimetype and font managing. Now im about to send another feature request for them.


15
tatane
Re: XOOPS 2.6 Internationalization/Local support
  • 2012/7/14 15:26

  • tatane

  • Just can't stay away

  • Posts: 649

  • Since: 2008/5/6 1


Hello

I just installed version 2.6 Operating on the svn. By local, I can access a modules/system/admin.php?fct=preferences&op=show&confcat_id=1

Only on my hosting I have a blank page with this message :

Quote:
Fatal error: Declaration of XoopsForm::getElements() must be compatible with that of XoopsFormContainer::getElements() in /homez.428/xoopsdem/www/26/class/xoopsform/form.php on line 27


I have the same error message when I try to acces to : modules/system/admin.php?fct=blocksadmin , modules/system/admin.php?fct=images , and other links

16
tatane
Re: XOOPS 2.6 Internationalization/Local support
  • 2012/7/16 9:06

  • tatane

  • Just can't stay away

  • Posts: 649

  • Since: 2008/5/6 1


Quote:

tatane wrote:
Hello

I just installed version 2.6 Operating on the svn. By local, I can access a modules/system/admin.php?fct=preferences&op=show&confcat_id=1

Only on my hosting I have a blank page with this message :

Quote:
Fatal error: Declaration of XoopsForm::getElements() must be compatible with that of XoopsFormContainer::getElements() in /homez.428/xoopsdem/www/26/class/xoopsform/form.php on line 27


I have the same error message when I try to acces to : modules/system/admin.php?fct=blocksadmin , modules/system/admin.php?fct=images , and other links


it's good it works, I had not activated the php 5.3 in my htaccess
Here is a small demonstration of a suitable theme in xoops 2.6

http://demo2.6.xoops-demo.com/

17
Mamba
Re: XOOPS 2.6 Internationalization/Local support
  • 2012/7/16 9:56

  • Mamba

  • Moderator

  • Posts: 11409

  • Since: 2004/4/23


Quote:
tatane wrote:
it's good it works, I had not activated the php 5.3 in my htaccess
Here is a small demonstration of a suitable theme in xoops 2.6

http://demo2.6.xoops-demo.com/

Tatane, very nice work!

All, if you have new themes for XOOPS 2.6.0 that you would like to share, please submit them in this new thread. Let's use Bootstrap and be creative!
Support XOOPS => DONATE
Use 2.5.11 | Docs | Modules | Bugs

18
tatane
Re: XOOPS 2.6 Internationalization/Local support
  • 2012/7/16 10:06

  • tatane

  • Just can't stay away

  • Posts: 649

  • Since: 2008/5/6 1


However, it would be nice to add in the default theme in 2.6 the function <{$block.module}>-<{$block.id}> to enable the management of custom blocks

19
irmtfan
Re: XOOPS 2.6 Internationalization/Local support
  • 2012/7/19 6:10

  • irmtfan

  • Module Developer

  • Posts: 3419

  • Since: 2003/12/7


Quote:


Many localization matters are already available inn core but developers/desginers never used them.
for eample please promote "image localization" for xoops theme designers.
we should encourage xoops theme designers to use local lang smarty code for images. (all images would be better but for images contain some characters would be nessesary)
currently everything is localized in themes and multi-language is implemented in official english themes released in xoops 2.5.5 except images.
eg: in xoops255/htdocs/themes/default/theme.html

<{$xoops_sitename}>

should be changed to:
1st way:
<{$xoops_sitename}>
2nd way:
<{$xoops_sitename}>

then the image should be renamed like below:
1st way:
xoops-logo.en.png

2nd way:
img/en/xoops-logo.png

please choose the preferred/best way for doing that. Then it should be promoted.

following the above for theme images, i recently see the developer of newbb introduced a very nice and professional fabulous work for fully customizing and localizing a module images.
IMO current core developers should follow this way and define a new image class in the core of xoops 2.6 and introduced it to all module developers. Then we can have the first CMS in the globe with the deepest image customizing/localizing.
This is a full customizing because It works without touching any core/module images. Therefore End user just need to copy all images in the "htdocs/themes" folder. So after updating a module he/she dont worry about losing its own created images by mistakenly overwriting some module images.

End user can follow the below instruction for customizing and localizing:
Priority for path per types:
NEWBB_ROOT -    IF EXISTS XOOPS_THEME/modules/newbb/images/, TAKE IT
*     ELSEIF 
EXISTS XOOPS_THEME_DEFAULT/modules/newbb/images/, TAKE IT
*     ELSE 
TAKE XOOPS_ROOT/modules/newbb/templates/images/. 
types:
*     
button/misc    language specified
*     
//indicator    -    language specified; 
*     icon     -    universal
*     
mime     -    universal
*/

So for example if i want to implement a new image set for all of my themes in the website i can copy them to the below folders:

themes/default/modules/newbb/images/icon
themes
/default/modules/newbb/images/language/english
themes
/default/modules/newbb/images/language/persian


You can see that I dont want to customize "rpg" and "mime" icons so the newbb will read the original ones from newbb original folders:
XOOPS_ROOT/modules/newbb/templates/images/rpg
XOOPS_ROOT
/modules/newbb/templates/images/mime


If i want to create a custom imageset for a special theme i can easily add to that theme folder:
themes/MY_THEME/modules/newbb/images/icon
themes
/MY_THEME/modules/newbb/images/language/english
themes
/MY_THEME/modules/newbb/images/language/persian


coders can read below to find the class that make it available:

The class is defined in newbb/class/icon.php file
eg: a function "getPath":

$path is_dir($theme_path."/{$rel_images}/{$type}/"
                    ? 
$theme_path."/{$rel_images}/{$type}"  
                    
: ( is_dir(XOOPS_THEME_PATH."/default/{$rel_images}/{$type}/"
                        ? 
XOOPS_THEME_PATH."/default/{$rel_images}/{$type}"  
                        
: ( empty($default) || is_dir(XOOPS_ROOT_PATH."/modules/{$dirname}/templates/images/{$type}/")
                            ? 
XOOPS_ROOT_PATH."/modules/{$dirname}/templates/images/{$type}
                            
XOOPS_ROOT_PATH."/modules/{$dirname}/templates/images/{$default}
                        
)  
                    );


Then function called "newbb_displayImage" in file newbb/include/functions.render.php
function newbb_displayImage($image$alt ""$display true$extra "class='forum_icon'"

    
$icon_handler newbb_getIconHandler(); 
    if (empty(
$display)) { 
        return 
$icon_handler->assignImage($image$alt$extra); 
    } else { 
        return 
$icon_handler->getImage($image$alt$extra); 
    } 
}


so module developers can use this function very easy like this:
$xoopsTpl->assign('img_newposts'newbb_displayImage('topic_new',_MD_NEWPOSTS));
$xoopsTpl->assign('img_hotnewposts'newbb_displayImage('topic_hot_new',_MD_MORETHAN));
$xoopsTpl->assign('img_folder'newbb_displayImage('topic',_MD_NONEWPOSTS));
$xoopsTpl->assign('img_hotfolder'newbb_displayImage('topic_hot',_MD_MORETHAN2));
$xoopsTpl->assign('img_locked'newbb_displayImage('topic_locked',_MD_TOPICLOCKED));

$xoopsTpl->assign('img_sticky'newbb_displayImage('topic_sticky',_MD_TOPICSTICKY));
$xoopsTpl->assign('img_digest'newbb_displayImage('topic_digest',_MD_TOPICDIGEST));
$xoopsTpl->assign('img_poll'newbb_displayImage('poll',_MD_TOPICHASPOLL));


Please add this class in the core. Then XOOPS will be the first ever CMS that have the fully customized images feature.
Also please if you can take a look at this feature:
Image creator class
I think it is very nice to create pictures for different languages automatically.








20
DCrussader
Re: XOOPS 2.6 Internationalization/Local support

To localization, use locale names instead of portuguese_br and portugueuese_pt, they're should be pt-BT and pt-PT.

Getting out of this 1.3 model of maintaining 4-10 files per module.
2 Files
---- module_admin_name.ini
---- module_site_name.ini

Getting out of PHP DEFINE statement, which is used here like devil's read the bible.
Adopt INI files, J! is not the only CMS using it, as u can see bellow, bigace
http://wiki.bigace.de/bigace:administration:languages
uses INI files too.

This
define("_AM_SENDTOUSERS","Send message to users whose:");
can look as
MOD_SOMETHING_AM_SENDTOUSERS=Send message to users whose:
much easier for reading and maintaining up to date.
May The Source Be With You!

Login

Who's Online

309 user(s) are online (163 user(s) are browsing Support Forums)


Members: 0


Guests: 309


more...

Donat-O-Meter

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

Latest GitHub Commits