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.

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_systemseg: 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:

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.

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.

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.

[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]

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

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.