There were two language defines that were not added in changelog.
In protector modinfo.php this was added:


Please check if your translations have this new defines.
Thanks.

Syntax error in /language/english/search.php
Line 24 - define('_SR_SEARCHRULE', 'Seach Rule');
should be Search Rule
.... more to come (hopefully they're few only).

Quote:
Thanks! It's now fixed in SVN.

Since you have to most experience with translations, would be interested to help us by coordinating the translations, and eventually making recommendations on how to streamline the process?

I'd love to help, but XOOPS is incompatible with everything known. Coordination on current language files is nearly impossible. Recommendations was made year ago, when 2.3 was latest xoops and the team leader was DJ. Now no one knows who is, is it true that Onokazu left Cube Legacy and is back here ? What's his vision about 2.6 ?

For current tree 2.5:
- Too many language files for core and 3 modules.
- Administration in language tabs separated with "# that goes for comments", J! 1.7 takes the worst points from XOOPS - and the result is clear. 1.0 was translated in over 80 languages, 1.5 in over 50 and 1.7 in few. Also there are some files that says nothing to the regular translator. This declarations should be changed by the core. Or in one file not in few. You can't put in header of most language files - ENCODING UTF-8 and in the same time to release all as ANSI. Check /language/xxxx/locale.php - too large and full of crap. this file can look like this:


Clean and simple. Current one is way too worst. for 4 line declarations, 2k useless crap.

And what we talked about cleaning the code and language files out of mess. XOOPS 2.5.3 is full of deprecated strings.

/Modules/System/Language/English/Admin/Preferences.php
Line 15-21
Line 27-33

Empty declarations after each line, Define - Site Name is ok, but define Site Name Description - is empty, just remove the damn empty definition. Or you want to be more detailed like the J! 1.7 language maintainers "No Articles here means, that there is no article in category" (I don't think there are so dummy English users anyway....) Everyone knows how looks empty category or what site name means in this case. So from line 37 to the end every definition which ends with DESC is empty, better removed.

Also there are missing guidelines:
Do not translate XOOPS, jQuery, Google, AdSense, all 3rd party extension names, this is not applies to modules.
Do not use Google Translator or any other machine translation services to make your translation available.
Do not loose time to maintain ISO Translations, over 99.9% of the Hosting Providers world wide supports Unicode UTF-8 and is default encoding.
(Just examples)

Also in some languages, such as Balkans (Serbian, Bulgarian, Russian, Croatian, Macedonian, some words are too larger then they're original.

Taking the following example
Find Users in English is
Tyrsene na potrebiteli in Bulgarian and is
Baraj koristnici in Macedonian

No idea how is solved in 2.5, but in 2.3 was truncated on Tyrsene na
In 2.4 was
Tyrsene na
potrebiteli

One line message on two lines in the menu.

The whole menu is useless, all this User tasks can be done in one User menu, such as let say User Management - and there u can search, ban, add, block, rename, move from group to group.

The biggest problem still remains the reordering and maintaining language files full of crap.

The string "The %s latest registered users" is deprecated since 2.1 release, but still present in the language files. Why ? I have prepared subdomain for XOOPS localized support someday (http://xoops.cmsbg.info/) and the default administration shows - Administrative tasks, Installed Modules and in right News from XOOPS, where do u see the old 1.3/2.0 Administration with last 10/20 registered users.

Since XOOPS differs from J! 1.7 language maintainers and category image is not counted as category avatar, why Avatars is a standalone icon since is used only for Users. XOOPS itself even don't have content module, so some of this tasks can be moved in max 5-6 global tasks.

Users
Avatars - User Management
Groups - User Management
Find Users - User Management
Mail Users - User Management
User Ranks - User Management
Users - User Management

Content
Content (missing module) - Content
Comments - Content
Smiles - Content
Image Manager - Content


Themes as word don't differs much from Templates, which is confusing. So make themes skins or move templates as part of the themes.

System
Themes - System
Maintenance (single option with shortcut ?) - System
Preferences - System
Modules - System
System Configuration (?) - System

Help
Wiki - wiki.xoops.org
Forums - forum.xoops.org
Modules - there is no such site
Developer Docs - no idea if exists.

With this changes and fights ... most of the XOOPS modules are incompatible with any existing version. Mithrandir XOOPS 2.2 uses own structure for the modules, those for 2.0 are loosing they're compatibility in 2.3, those for 2.3 no longer works on 2.5. So whole section modules - have to moved into one category Archive, and to be created new one with the compatible modules for the current tree.

And since 2.6 will come in one or another way, why not let what's left from the community to decide what to be used as Language files - INI or POT. Then one monitoring will look like this:
(Listing is for sample application)
Main list of all files - https://www.transifex.net/projects/p/jd-i18n/
Core translation progress
https://www.transifex.net/projects/p/jd-i18n/resource/admin_en-gbcom_jdownloadsini/

Here anyone can see that Estonian, Portuguese and Thai translators sleeping and u can find replacement easily :)

In current tree and version, there is one Full translation (Italian, if they're add the the 2 new strings for 2.5.3), two on the way. Rest can't be counted as translation if they're for older releases and there are language changes.

I would like to see what Onokazu will say, since XOOPS 1.3 and 2.0 till some time was created and leaded by him. And to see again strong Balkans community like till 2.0.18.

(Sorry for the long reply, but everything is language related)
Btw, does this XOOPS - https://www.transifex.net/projects/p/xoops/, have something related with XOOPS.ORG ?

Thanks for all your input and suggestions! It is very much appreciated!

Let's work on this together, so we can streamline the translation infrastructure and make it easier for the translators.

What do you recommend - using INI or switch to Gettext? Eduardo implemented Gettext in his RMCommon framework, so we could utilize it for the whole XOOPS Core, if the Core Team decides that it is doable, and if there are benefits for the translation process. Or we can just streamline our current files and continue with the INI approach.

What is your suggestion?

Quote:
Unfortunately, it's one of the several XOOPS assets that DJ hijacked and keeps hostage

POT is a bit complicated for Windows users, but is ok too if there is one Cerberus to deal with core and module developers to not release messy files. Taking example with another well supported CMS - Druapl and D useses only POT files, but when you extract main core files from core to put them to Transifex or another online translation platform - you will get error messages which requires to execute Linux application on Windows platform to see where is the bug and another to fix it. Well this Cerberus - can prevent from releasing such crap :).

For Drupal core developers POT is faster then INI, for me (well this is only by monitoring Drupal, is buggy..... Clean Drupal installation, and u have to click on each click-able option in Administrative/User interface to get it inserted in the main language file, probably this is Drupal bug). If here core developers and module developers provide and POT (corrected with some requirements sets by Infidex and Transifex then is ok).

INI Files are cooler, first presented in J! 1.5, they're looked like:
COM_DEFINE_SOMETHING=Something goes here
now they're look like
COM_DEFINE_SOMETHING="Something goes here"
(which slows down offline translation, when translator uses NotePad +)
1.5 INI Files quoted text looks like:
COM_DEFINE_SOMETHING_QUOTED=Here goes the "quoted" text.
1.7 INI
COM_DEFINE_SOMETHING_QUOTED=Here goes the _QQ_"quoted"_QQ_ text. (which makes double work for offline and online translation).
Some extensions (modules) developers avoid it, by adding ' instead of ", so the text looks like Some 'quoted' text goes here.

For J! Developers INI with " " is faster then POT. Well I can't say that, 1.7 core is too buggy and currently we are working to remove permamentlly the global cache which makes additional 20MB daily on empty site. (This is another topic). So I can't confirm that INI files with "" is faster then old way, for me is even slower, but that comes from the core.

For Drupal developers - POT files are better, for DJ too. In the pot files every developer can reorder the languages in every new release or/and sub-release. In offline mode with tools such as POEditor or online such as Transifex - the translator see only the changed/empty strings.

In conclusion... POT (no matter how much I lost nerves in past with GET Text), Just there must be and guidelines for core devs and module developers.

For sure there are at least 2 professional developers (Catzwolf and Onokazu), that can say which way is faster, to keep maintaining XOOPS faster platform ever (no matter that is just platform right now). If Onokazu is back, then and Herve may return, another damn good XOOPS professional. He can says too (based on some tests which way is better). But current Nuke define way is worst.

Both standards are covered by GNU Gettext, since in J! 1.7 u can use both files, there will not be a problem to set the core in INI or POT and modules to be in reversal way. If there is a tool like Localize for 1.7 and build-in translator for Drupal, translator will not care much about what you will set as standard for core, rest.

Let say 2.6 or 2.5.4 comes out with POT files. But catzwolf (with the best ever download management module made) can use INI or both. GNU Gettext handles both.

(That's why I hate General Warez License v2 and 3). Creative Commons for the win :)

Any updates on POT/INI issue, on which version can be expected ? Current tree from next or 2.6 ?

Any language changes in 2.5.4 Beta ?
Module - new/changed/removed ?

Quote:
This will be discussion point for 2.6.

Quote:
Please see the bottom of the XOOPS 2.5.4 announcement.

I've updated several things based on your input. But this is just a start. You've raised some very good points, so I'll be looking into the translations in depth.
If you're interested and willing, I would like to work with you on this, so we can ensure that the translations are up-to-date, and we get rid of all the stuff that is old and not used anymore.

Count me in. Currently I'm making dual translation for 2.5.4 to bg-BG and to en-BG. But probably will never release it, if changes are not added in the way I want:

Like Trabis:


or by adding # to the end

# Here starts 2.5.4 additions:
......

Instead of adding such:


This is time consuming to verify every single definition, the above block can looks like this:

Changed /language/english/calendar.php (since is already commented and placed on the end, every translator will find it in a second)
Changed /modules/system/languages/admin.php
Removed (obsolete) /modules/system/language/something.php
Added /modules/system/language/replacement-for-the-obsolete-file.php

Clean and simple.