Fork me on GitHub
Get XOOPS XOOPSXOOPS FAQFAQ ForumsForums NewsNews ThemesThemes ModulesModules
New Posts New Topics All Posts All Forums Index General Modules Themes Development International XOOPS.org

Search

Nominate XOOPS!

Learn XOOPS Core

Donat-O-Meter

Make donations with PayPal!
Stats
Goal: $100.00
Due Date: Jul 31
Gross Amount: $15.00
Net Balance: $14.11
Left to go: $85.89

Donations
Anonymous ($15)Jul-20

Local Support

Advertisement

XOOPS Code hosted on SourceForge

Cumulus Tag Cloud

- 2 2.5 2.6 3.0 4 6 2013 Abuse adslight Android AntiHarvesting AntiMalUser AntiSpam API Apple Battlefield billige Bootstrap Captcha cell chronolabs content CĂN demo docek download Dresses evden eve facebook Fat Food for free Gateway Google Guide herre Home Honeypot HP html5 Human HỘ IP iPhone jQuery List log Loss mobile module modules Monster new newbb news NHÀ online PARK phone PHP Prevention profile project Protector publisher Rapid RESIDENCE responsive review Rights rmcommon Room security Sentry site Smartphone Smarty Smoking Solution Spam Studio tag tags tdmcreate template The Theme themes User userlog web weight Wishcraft xoops Xortify

New Users

Registering user

# 137636

mzmaker05

Welcome to XOOPS!




Bottom   Previous Topic   Next Topic  Register To Post

« 1 2 (3) 4 5 »


#21 Posted on: 2012/8/8 1:13 Re: XOOPS 2.6 Internationalization/Local support
Quote:

To localization, use locale names instead of portuguese_br and portugueuese_pt, they're should be pt-BT and pt-PT.
.....
Getting out of PHP DEFINE statement,
....
uses INI files too.

+1000

This is requested many times in the sf.net xoops feature tracker.
Core team should address it ASAP.
INI files has the first priority in the internationalization/localization features.
once we had INI files we can:
1- develop lang tools
2- auto diff
3- full customization of language files in themes like this:
themes/YOUR_THEME/module/YOUR_MODULE/language/YOUR_LANG
4- have different definitions for different clones of the same module. very useful and needed.

But the basement for all of the above features is the INI files.


Top


Ready for Romance
First Persian Harry Potter Site(English added) | Persian Support Site | Xoops Persian Project
irmtfan
Module Developer
Module Developer
Joined:
2003/12/7 14:14
From In the middle of nowhere
Group:
Registered Users
Community Coordinator (temporary)
Posts: 3367
(Show More) (Show Less)


#22 Posted on: 2012/8/8 1:14 Re: XOOPS 2.6 Internationalization/Local support
Is INI the best option, better than Gettext?

Eduardo made Gettext working in his RMCommon modules, so I am hoping that we can take his solution and deploy in XOOPS 2.6.0, but as always, it will be up to the Core Team....

BTW - my understanding is that because Gettext files are compiled, they are also faster. Any experience with that?

Top


Please support XOOPS & DONATE
Use 2.5.7 | Debugging | Requests | Bugs
Mamba
Moderator
Moderator
Joined:
2004/4/23 13:58
From Ohio, USA
Group:
Webmaster
Registered Users
Designer Group
Posts: 8032
(Show More) (Show Less)


#23 Posted on: 2012/8/8 1:46 Re: XOOPS 2.6 Internationalization/Local support
IMO and i insist it is just my point of view:
PO files are not readable without language editors like POEDIT but INI files are simple and can be read even by a notepad.
Because we need our very simple webmasters without any knowledge change the language files themselves IMO we can use INI files.
Gettext is just a little faster than INI but many disadvantages regarding simplicity.

Just my opinions.


Top


Ready for Romance
First Persian Harry Potter Site(English added) | Persian Support Site | Xoops Persian Project
irmtfan
Module Developer
Module Developer
Joined:
2003/12/7 14:14
From In the middle of nowhere
Group:
Registered Users
Community Coordinator (temporary)
Posts: 3367
(Show More) (Show Less)


#24 Posted on: 2012/8/9 10:01 Re: XOOPS 2.6 Internationalization/Local support
Gettext POT/PO files are readable with NotePad + which should present on every translator/developer desktop with Windows OS.
PO/POT will open double work for developers, as already noticed, some deserves POT to stop loosing they're time and playing with formatting.

For Joomla! which was best core developed until last release of 1.6 followed by 1.7 and 2.5

INI files with "" - is more faster then even POT files, well for me as end user, 2.5, 1.6 and 1.7 ruined the myth for the best cms ever with the awfully written core ever.
But INI files with "" still causes a lot of troubles on TX platform, no matter that I'm working really hard with Infidex (bcz with joomla.org cooperation is impossible) to make TX platform fully compatible to this stupid standard.

INI files without "" used in 1.5 are better, and everyone with 5 minutes free time can see the difference in speed between 1.5 with demo content and 2.5 demo content. Just out of words how slow is 2.5


J! 2.5 INI file
NAME="Name"
TITLE="Directory"
NAVIGATE TREE="Navigate Tree"
ADD LISTING="Add Listing"
EDIT LISTING="Edit Listing"
ADD CAT="Add Category"


J! 1.5 INI file
NAME=Name
TITLE
=Directory
NAVIGATE TREE
=Navigate Tree
ADD LISTING
=Add Listing
EDIT LISTING
=Edit Listing
ADD CAT
=Add Category


By adopting J! 1.5 INI files structure, XOOPS gains:
- The need of maintaining 4 to 10 files per module with double content will gone, 1 file is enough
- Formatting lovers can't play with language files anymore
- Easily maintaining content such as web site addresses or mail templates within language files
Quote:

1- develop lang tools

(XOOPS need diplomat to solve problems with rest communities)
Extended on above - developing function for syncing completed language files from TX to the current core and installed modules (work in progress by banned CMS)
Quote:

auto diff


Absolutely, current way is awful.

Quote:

full customization of language files in themes like this:
themes/YOUR_THEME/module/YOUR_MODULE/language/YOUR_LANG


This missing feature stops XOOPS from evolving.

Quote:

have different definitions for different clones of the same module. very useful and needed.


Also there is a TEXT OVERRIDE, where users can use different words for something u love to use in XOOPS, with text override u can keep your beloved WEIGHT and users to use ORDER or POSITION, in this way of thinking will eliminate the need to edit the misleading terminology still used somewhere in XOOPS, every user can rewrite
WEIGHT - to ORDER, Posted to Published, Account to Profile.

Regarding POT, bitcero throw the bomb and get away, RMCommon supports only en.po, which for me is not support at all. There is the bug with this framework and all of his modules for not accepting anything other then en.po, also as POT files, there will be loosed a lot of time for finding and removing Spanish/Brazilian words from English files.

Top


May The Source Be With You!
DCrussader
Friend of XOOPS
Friend of XOOPS
Joined:
2005/7/4 2:57
Group:
Registered Users
Posts: 551
(Show More) (Show Less)


#25 Posted on: 2012/8/9 21:01 Re: XOOPS 2.6 Internationalization/Local support
thank you DCrussader. I like your post very much.
Quote:

Formatting lovers can't play with language files anymore

+100
Now there is no standard for it too.
definitions are just definitions and it should be a rule for new developed modules that nothing is allowed like this:
define('_MD_USER_POSTS''Posts: %s');

or worse than that this:
define("_MD_NEWBB_SEEWAITREPORT","There were <font color="red"> <b>%s</b> Contributions reported </font>");


DCrussader please pay attention im about to write regulations/rules to standardize the internationalization/localization coding.
I cannot write rules to standardize all XOOPS coding system. It needs an expert developer.

Anyway, i sent a feature request with the highest priority to sf.net tracker for choosing INI or Gettext.





Top


Ready for Romance
First Persian Harry Potter Site(English added) | Persian Support Site | Xoops Persian Project
irmtfan
Module Developer
Module Developer
Joined:
2003/12/7 14:14
From In the middle of nowhere
Group:
Registered Users
Community Coordinator (temporary)
Posts: 3367
(Show More) (Show Less)


#26 Posted on: 2012/8/10 4:50 Re: XOOPS 2.6 Internationalization/Local support
Quote:

I cannot write rules to standardize all XOOPS coding system. It needs an expert developer.


You don't need to be developer to set them for the language part, the other point is who will follow them and how :)
Monitoring is another missing point here.

Adopting Gettext will be mistake, specially for non-native English speaking developers, they need to edit both files when a bug in language is discovered - once in the code next in the POT.

INI - just find the way which will be best, 1.5 clean or 2.5 messy.
Clean example why POT should be avoided, PHP DEFINE too
(No one except me understand Bulgarian, but u will see on the following examples, what's translated and what's not)
http://drupalcamp.bg/ - something like promotional site for Drupal in Bulgaria, acting as anti-advertise, the whole core is untranslated, only content is in Bulgarian, thanks, but no thanks of such advertising.

Drupal never will be translated to anything different then English, bcz of two points:

1. English - Drupal English is most awful language I've ever seen.
2. GNU GETTEXT

The only good point with Drupal, is that have unbeatable CCK
------- That's all for Gettext -----------------
Solved and unsolved bugs on Infidex with both versions of INI structure.
------------ Presuming XOOPS 2.6 uses INI (no matter which version) -----
1. Content of the language file must not be over 150KB, otherwise some ppl like Cesag will give up of waiting for every auto-save on TX.
2. There should be not any empty strings such as
COM_SOMETHING="" or COM_SOMETHING=
3. Filenames must not be longer then 50 characters including .ini extension.
example for bad naming - en-GB.plg_cck_field_validation_letter_number_only.sys.ini
4. There is no way of maintaining
English or French only translations, translations must be based on en-US or en-GB and translated to fr-FR or fr-CA and en-AU or else. For arabians there is ar-AA already if they're country is not mentioned in particular. Farsi is another point.
4.1. Double resources are not allowed, this means:
If there is French (French) translation, there can't be French translation.
4.2. Source language can't be English (should be en-GB, or en-US)
5. There can be plural forms in INI files and this feature must be used
6. If is used INI structure similar to those in 2.5 of Joomla, developers should be aware of adding URLS into language files
Quote:

Double quotes in the value should be written as "_QQ_" or as "
NEVER use an escaped quote " as these will break in php 5.2.x

7. Local.php should be evolved into another file

To allow setting proper calendar function for Farsi (it's not only Iranians who uses different calendar)

Top


May The Source Be With You!
DCrussader
Friend of XOOPS
Friend of XOOPS
Joined:
2005/7/4 2:57
Group:
Registered Users
Posts: 551
(Show More) (Show Less)


#27 Posted on: 2012/8/10 21:23 Re: XOOPS 2.6 Internationalization/Local support
ok
i did what i can.
XOOPS localization-customization-translation Standard.doc
Please read and correct my english.

Also as you can see, local numbers are incomplete because IMO it is not important feature.
And as always there are many parts need to be done in xoops core before module developers can do anything about them.


Top


Ready for Romance
First Persian Harry Potter Site(English added) | Persian Support Site | Xoops Persian Project
irmtfan
Module Developer
Module Developer
Joined:
2003/12/7 14:14
From In the middle of nowhere
Group:
Registered Users
Community Coordinator (temporary)
Posts: 3367
(Show More) (Show Less)


#28 Posted on: 2012/8/10 23:26 Re: XOOPS 2.6 Internationalization/Local support
Local numbers ? I don't get that part

Top


May The Source Be With You!
DCrussader
Friend of XOOPS
Friend of XOOPS
Joined:
2005/7/4 2:57
Group:
Registered Users
Posts: 551
(Show More) (Show Less)


#29 Posted on: 2012/8/10 23:57 Re: XOOPS 2.6 Internationalization/Local support
local numbers are just some cosmetic and nice looking for local parties.
every one is familiar with latin numbers 0 1 2 3 4 5 6 7 8 9
Quote:

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


read from here:
http://xoops.org/modules/newbb/viewto ... id=347672#forumpost347672


Top


Ready for Romance
First Persian Harry Potter Site(English added) | Persian Support Site | Xoops Persian Project
irmtfan
Module Developer
Module Developer
Joined:
2003/12/7 14:14
From In the middle of nowhere
Group:
Registered Users
Community Coordinator (temporary)
Posts: 3367
(Show More) (Show Less)


#30 Posted on: 2012/8/22 6:36 Re: XOOPS 2.6 Internationalization/Local support
i update the XOOPS localization-customization-translation Standard.doc and fix some items in image customization/localization.
Also i add the local numbers part.
It is now complete from my side.
Please contribute more.
I read some articles in the net and assess Joomla and Drupal way for localization and cannot find them more completed than the above document.
Also now our main problems are:
- core team did not response to the feature requests in sf.ent
- core team did not follow these advices (eg image localization) in 2.6alpha1/themes/default and 2.6alpha1/modules

Top


Ready for Romance
First Persian Harry Potter Site(English added) | Persian Support Site | Xoops Persian Project
irmtfan
Module Developer
Module Developer
Joined:
2003/12/7 14:14
From In the middle of nowhere
Group:
Registered Users
Community Coordinator (temporary)
Posts: 3367
(Show More) (Show Less)




« 1 2 (3) 4 5 »



You can view topic.
You cannot start a new topic.
You cannot reply to posts.
You cannot edit your posts.
You cannot delete your posts.
You cannot add new polls.
You cannot vote in polls.
You cannot attach files to posts.
You cannot post without approval.
You cannot use topic type.
You cannot use HTML syntax.
You cannot use signature.

[Advanced Search]