Quote:
+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.

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?

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.

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


J! 1.5 INI file


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

Absolutely, current way is awful.

Quote:

This missing feature stops XOOPS from evolving.

Quote:

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.

thank you DCrussader. I like your post very much.
Quote:
+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:

or worse than that this:


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.

Quote:

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

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.

Local numbers ? I don't get that part

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:

read from here:
https://xoops.org/modules/newbb/viewtopic.php?post_id=347672#forumpost347672

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