1
Mamba
XOOPS 2.6 Internationalization/Local support
  • 2012/7/10 6:28

  • Mamba

  • Moderator

  • Posts: 11381

  • Since: 2004/4/23


There were several issues raised by Voltan (see here) and Irmftan (see here) in the Roadmap 2.6.0, as well as the recent NewBB thread

So this thread is to discuss all XOOPS Internationalization/Local Support issues.

It sounds like we need a dedicated team to test and address all of these issues. I hope, Irmtfan and Voltan will lead this effort.



Support XOOPS => DONATE
Use 2.5.10 | Docs | Modules | Bugs

2
irmtfan
Re: XOOPS 2.6 Internationalization/Local support
  • 2012/7/10 7:29

  • irmtfan

  • Module Developer

  • Posts: 3419

  • Since: 2003/12/7


internationalization (or localization) is different from globalization please do not conflict between them.

I can summarized our issues in localization in a easy readable list item by item.
1- local date functions:
- it is server side.
1-1- local output date function:
- solved many years ago by introducing "formatTimestamp" function. xoops developers should use formatTimestamp function in all output date/times.

1-2- local input date function:
- It gets the date from user and change it to number for storing in the database. The local function is not exist until now. no developer take care about this.
They used strtotime function but it just can handle Gregorian dates.
(note: Please pay attention that I talk about a totally different date system.
eg: in Gregorian this year is 2012 but in hegira this year is 1391)
topics related for more information:
https://xoops.org/modules/newbb/viewtopic.php?post_id=347361#forumpost347361
https://xoops.org/modules/newbb/viewtopic.php?post_id=347004#forumpost347004

a picture for visualizing the issue:
Resized Image

feature request here:
https://sourceforge.net/tracker/?func=detail&aid=3537303&group_id=41586&atid=430843

2- local calendar
- it is user side
- the current calendar is not capable. a new calendar called "JQuery UI datepicker" is requested by Voltan here:
https://sourceforge.net/tracker/?func=detail&aid=3405407&group_id=41586&atid=430843

and the first attempt for add that is done by timgno.
news: https://xoops.org/modules/news/article.php?storyid=6333
here you can see the discussion:
https://xoops.org/modules/newbb/viewtopic.php?topic_id=75249
It is the solution if local parties could add their own javascripts files.

3- local numbers.
- Latin based character territories ( and all of our xoops core developers are coming from these countries) are not familiar with "non-positional numeral systems" in the world but maybe you could understand if you read this wiki:
http://en.wikipedia.org/wiki/List_of_numeral_systems
eg: roman numeral system: http://en.wikipedia.org/wiki/Roman_numerals
( I think you are more familiar with roman numerla system. am i right?)
currently we have a function called number_format in php and it is enhanced by xoops previous developers. so developers (core and module) can use it like this:
xoops_load('XoopsLocal');
.....
XoopsLocal::number_format($VAL)

then in the lang file local parties can enhanced their own functions.
eg in persian:
function number_format($number)
    {
        if (
_JDF_USE_PERSIANNUM){
            return 
Convertnumber2farsi($number);
        } else {
            return 
$number;
        }
    }


Also in english one can format the number like it is in the current 2.5.5 release:
function number_format($number)
    {
        return 
number_format($number2'.'',');
    }


So just it needs to be added to all numeric fields (too many fields are exist in core and modules)

4- pdf maker: Voltan said tcpdf is capable for it. but i dont know much. he can explain and show us a demo.

5- LTR - RTL: In my opinion it is complete at least in the user area. In admin maybe we should do further attention.
the variable to load costume css and js is :


<{$xoops_module_header}>




3
Mamba
Re: XOOPS 2.6 Internationalization/Local support
  • 2012/7/10 7:57

  • Mamba

  • Moderator

  • Posts: 11381

  • Since: 2004/4/23


Irmtfan, this is an excellent post! Thank you!

I hope, other developers will join this conversation, so we can make sure that the needed features are implemented.

Also, please report any issues with the Blue Move modules, so we can fix them as we go....
Support XOOPS => DONATE
Use 2.5.10 | Docs | Modules | Bugs

4
irmtfan
Re: XOOPS 2.6 Internationalization/Local support
  • 2012/7/10 10:21

  • irmtfan

  • Module Developer

  • Posts: 3419

  • Since: 2003/12/7


First we should fix the core codes then we can proceed modules
below I listed the works that should be done on items one by one.

1-1- is done
1-2- core developers should response to this feature first.
http://sourceforge.net/tracker/?func=detail&aid=3537303&group_id=41586&atid=430843

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

3- core developers should ask one question. are they agree with this method?
xoops_load('XoopsLocal');
.....
XoopsLocal::number_format($VAL)

[edit]
I mean maybe core team are against of using number_format (borrowing a php function is not good) and they want to define a new function from scratch for this purpose.
for example the new function can be called "xoops_numeral_system"
Anyway if you search number_format in xoops core and modules you dont find any. so we can define a new function without being worry about the compatibility.
core team should response Then me or you or any body else can proceed.
[/edit]

4- Voltan should be in charged of that. pdf maker needs a close developer look.

5- IMO it is complete. (but im not sure completely)

5
redheadedrod
Re: XOOPS 2.6 Internationalization/Local support

Just a syntax type thing but with 2.6 I don't believe there is a $xoopslocal as it is all included in the $xoops variable if I understand what I read.

And the proper way to handle date/times should be to always convert to and from the Database compatible format. We should have a function or functions that convert an entered date/time to the database format and function(s) that display the database formatted date/time in the local format. This would make sense because to store this date you have to convert it regardless and no sense converting it to a localized variable to have to then convert it again to a database compatible date. Allow the PERL format string for dates to be changeable in the preferences and this then get applied to the dates accordingly. This should allow for easy localization and make sure that all module writers only use these functions to access the date/times.

Not sure if this is the right place to mention this but I wonder if it would make sense to change the structure of the language files as well or go to a different system altogether. Currently we load a file related to what we want to do and this incurs a lot of duplication.

Would be nice if we could have a standardized library of language constructs that module writers could use and if they use just those standardized constructs there is no need to have to do anything. It just uses the standard library of constructs and thus would work well in any language supported by the standard library. If the necessary constructs don't exist in the standard library then the module can add the ones they need. Not sure if this would be a big hit on memory used but seems like all of the duplication is unnecessary. There has to be a better way and it seems like this has been discussed before. Using a standard library would not do away with the module language files but should make them a whole lot smaller and in some cases totally unnecessary.

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

  • irmtfan

  • Module Developer

  • Posts: 3419

  • Since: 2003/12/7


redheadedrod:
maybe i dont understand you well but i cant see a $xoopslocal variable in the 2.5.5

There is a xoopslocal class located at htdocs/class/xoopslocal.php

Quote:

We should have a function or functions that convert an entered date/time to the database format

Ok it seems you repeat my request. The problem is that entered date/time is in local format and we dont have any local function for this purpose. what do you offer as a developer?
Quote:

and function(s) that display the database formatted date/time in the local format.

we already have "formatTimestamp". do you mean anything else?

ps:
Maybe a developer could understand you better. please write your post in more easier basic english :d

7
redheadedrod
Re: XOOPS 2.6 Internationalization/Local support

Sorry wrote that from work after no sleep...

The $xoops variable comment was related to 2.6 NOT 2.5.5.

As to the rest maybe I don't understand.. When I looked for the date format for a project I was doing back with xoops 2.4.5 there was no supported method to change the date formats in core. This changed somewhat with 2.5.5 but seems like it never has worked quite right for everyone. I never really messed around with it but seems like the date format stuff should be relatively simple to accomplish. With 2.5.5 I don't recall there being a way to change this in the preferences either.

The PERL configuration string is the name of the string you use to configure the format of the date string for certain PHP functions. It was first used in the language PERL and was duplicated with PHP (And others) so it is generally called the PERL format date string because of this...

This is when you see things like "d m Y" to describe the date format. This would be the PERL configuration string I mentioned.

8
irmtfan
Re: XOOPS 2.6 Internationalization/Local support
  • 2012/7/11 4:45

  • irmtfan

  • Module Developer

  • Posts: 3419

  • Since: 2003/12/7


redheadedrod:
you misunderstood me. The principal of localization is enhancing the core codes to accept different systems not just different "formats" or different "languages".

for example about date/time i talked about a different "date system". please read below to understand the issue:

from ages ago xoops use some definitions for output date/time formatting.
they are located in htdocs/language/LANG/global.php
define('_DATESTRING''Y/n/j G:i:s');
define('_MEDIUMDATESTRING''Y/n/j G:i');
define('_SHORTDATESTRING''Y/n/j');


from 2.5.5 there are some new definitions:
/**
 * Additions to 2.5.5
**/
define('_DBDATESTRING''Y-m-d');
define('_DBTIMESTRING''H:i:s');
define('_DBTIMESTAMPSTRING''Y-m-d H:i:s');

[off topic]
it seems they are for input date/time formatting which i dont know why we need These database date/time formats. maybe to store date/times in the database with other formats but i still cannot understand why we need different formats for storing date/time in the database. The "int" format for storing in the database is definitely fine. why you want to make it messy and harder? i mean then the local parties like us have more issues to change them trough the date system)
[/off topic]

Also we have below variables in htdocs/language/LANG/locale.php
define("_TODAY""Today G:i");
define("_YESTERDAY""Yes\te\rday G:i");
define("_MONTHDAY""n/j G:i");
define("_YEARMONTHDAY""Y/n/j G:i");
define("_ELAPSE""%s ago");
define("_TIMEFORMAT_DESC""Valid formats: "s" - " _SHORTDATESTRING "; "m" - " _MEDIUMDATESTRING "; "l" - " _DATESTRING ";""c" or "custom" - format determined according to interval to present; "e" - Elapsed; "mysql" - Y-m-d H:i:s;"specified string - Refer to http://php.net/manual/en/function.date.php" rel="external">PHP manual.");


And XOOPS core development team must move those file definitions to the database in the future 2.6 version along with too many definitions that i mentioned before.
Quote:

- Please move all possible configurations to the database. eg: captcha configs, image configs,... I can understand some important configurations like debug should be in file because maybe the end user lost its connection to the database. but all other configurations should be in the database. it is just confusing for new users to struggle in the whole xoops files. Also please unify all important configurations to the xoopsconfig.php


But the above are just formatting strings and i dont talk about formats

Persian community use a different date/time system and i can show you by a simple example.

Today is "2012-07-11" in Gregorian Calendar.
Today is "1391-04-21" in Hegira (or Hejira) Calendar.

So you can understand we need completely different functions for this date system.

I mean we can not use php "date" function. we wrote a "jdate" function and use it just like date function.
jdate will change the date system from Garegorian to Hegira

eg (refer to the image i mentioned before):

Database --> "2012-07-11" ---formatTimestamp---> jdate local---> "1391-04-21" --> userside

Therefore for example to localize the "formatTimestamp" xoops function we just need to add below codes to the original "formatTimestamp" in our language locale.php:

// Start hacked by irmtfan
    
if (_JDF_USE_HEGIRADATE && $format != 'mysql' ){
         return 
jdate($datestring,$usertimestamp);
       } else {
             return 
ucfirst(date($datestring,$usertimestamp));
           }
    
// end hacked by irmtfan



hopefully everybody in latin base territories using Gregorian calendar could understand now the localization.

9
irmtfan
Re: XOOPS 2.6 Internationalization/Local support
  • 2012/7/11 6:00

  • irmtfan

  • Module Developer

  • Posts: 3419

  • Since: 2003/12/7


for more information about different date/calendar systems please read from wiki:
http://en.wikipedia.org/wiki/Iranian_calendars (persian community used this)
http://en.wikipedia.org/wiki/Islamic_calendar ( Arabic community used this)
http://en.wikipedia.org/wiki/Gregorian_calendar ( used in the globe)

10
redheadedrod
Re: XOOPS 2.6 Internationalization/Local support

Storing dates and times in the standard database format allows you to perform queries based on those "standardized" dates. The databases generally can perform specialized searches and manipulations of this data with built in routines thus the reason why we store in this manner.

Sounds like to "globalize" we just need a way to convert back and forth between different calendar types but do it in a manner that we can use generic statements to store or retrieve the data that would translate for the different calendars. Then promote the use of these core routines to module developers.

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 but by using these core routines that take care of the conversion for you they do the "dirty" work. Internally the date/time is normally stored as so many seconds since a certain time/date but is seldom accessed directly in that manner.




Login

Who's Online

169 user(s) are online (48 user(s) are browsing Support Forums)


Members: 0


Guests: 169


more...

Donat-O-Meter

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

Latest GitHub Commits