I update the theme related images section to compatible the procedure to the recent 2.6.0 alpha 1 as much as possible.
because If we use the lang code (eg: en) no extra smarty is needed.
Quote:

with the above method we dont need to touch current smarty variables in class/theme.php

then just need to promote theme creator to use it like this:
new smarty:
<{$theme_img}>/<{$xoops_langcode}>/logo.png

or using the very old smarty:
<{$xoops_imageurl}>img/<{$xoops_langcode}>/logo.jpg

also we have this smarty variable:
<{xoImgUrl img/logo.png}>

three smarty for the same thing is available. so we should define a regulation for creating new themes.


Edit:
IMO whenever core team decide to use one of INI Gettext, ... instead of current php definitions xoops can replace current language name with language code:
eg: "english" with "en-us"

zyspec wrote me in a pm:
Quote:

the good reason for moving images from modules/MODULE/images to modules/MODULE/templates/images is:
1- Xoops core didnt read and should not read module images so the location of module images is not important for core

2- module images are user side not admin side. they should only be used in templates and not any other place in the module like admin side. for module admin images or logo or credits and like that the module developer can/should use any other place like modules/MODULE/images. the users of the module (webmasters) dont need deep customization for themselves. just the user side is important regarding full customization and localization.

3- by moving images to modules/MODULE/templates/images we can customize them in theme in the appropriate, comprehensive and same look location like themes/THEME/modules/MODULE/images just beside module html templates.

Quote:

huum then how it can be localized?

Now we have this:

userside layer --> localization layer --> server db

userside layer <-- localization layer <-- server db

And working with an integer that dont have any format is easy but a date field in the database have a format like yyyy-MM-dd hh:mm:ss

Anyway i dont know about what you said. it would be great if you can show us an example.
Thank you for your feedback.

Dont know about which images we are talking, but if it are the overall in every module used basic images concerns like: edit, print, activate/deactivate, pdf, and so on, I prefer to put them in a central core image diectory. Outside directory module/MODULE/templates/images
It really makes no sense to upload al the same images many times within each and seperate module. If you would like to change some images you have to run through all the installed modules.

The goal of customization and localization is:
- user (webmaster) just touch the themes/default for overall look of the site and themes/THEME for change in each theme
The user side = themes and everything should be done only in themes folder.

It means all images, templates and even language files (translations) should be read with this priority:

- IF EXISTS XOOPS_ROOT/themes/XOOPS_THEME/modules/MODULE/, TAKE IT;
ELSEIF EXISTS XOOPS_ROOT/themes/default/modules/MODULE/, TAKE IT;
ELSE TAKE XOOPS_ROOT/modules/MODULE/templates/.


Now the above customization is almost implemented (just need to set the default theme priority) for module templates.

It should be implement for module images and in the future for module language files (translations)

Also we should define what is core. In this customization method the core = system module.

So the XOOPS_ROOT/images should be removed and all images related to core should be moved to XOOPS_ROOT/modules/system/templates/images
so we have:
XOOPS_ROOT/modules/profile/templates/images
XOOPS_ROOT/modules/banners/templates/images
and ...

Then it can be customize for overall look (all themes) in themes/default and for each theme in themes/THEME.

Quote:
The goal is exactly this.
let me explain that:
1- we should define a image class in core 2.6.0. ( Now it is exist in newbb module in newbb/class/icon.php and just should be turn to a core class)

2- There is a function called displayImage (in the image core class or somewhere else) and should have the following parameters

Now in newbb it is:

and function setImage is in newbb/class/icon.php

You can see the beauty of this method.
please look at newbb/class/icon.php and newbb/include/functions.render.php for more information.

The programing is finished in core and after that all module developers can use this class very very easy like this:

in any module the module developer can use this images core class like this:

1- module developer define all its own images and icons in a file like MODULE/images.php


(core image class should read it from all modules)

2- assign a smarty variable in the script like this:

and just use that in the theme/templates

<{$icon_pdf}>

will be:

and:

<{$icon_postedit}>
will be:


and maybe we can use one module icon in another module: eg: xoopspoll icon poll.png in newbb module

<{$icon_poll}>
will be:


I hope i could explain it totally.
I need your opinions. im not a coder and maybe some codes are not correct.


Edit:
possible question:

what is the benefit of having the themes/default prior to modules/MODULE/templates/?

The big advantages are:
1- when you update a module you dont overwrite the custom images
2- new users will not confused because we guid them that all customization/localization can be done inside themes folder and no where else.
3- we can do anything with modules in the future and even move them outside wwwroot and all themes are still worked just fine.

Images ?
Did I've said it already, images like
Open, Save, Post, New Thread, Reply, PM etc.
should be text declaration within INI files, CSS designers will make them looking like buttons, for example SimpleMachines Forum 2.0.2

Translators are not Graphics Designers and most modules, currently existing for XOOPS 2.5.5 and lately moved to 2.6 will remain untranslated - whole interface, error messages etc. translated, but images in English - yack!

any official confirmation in which alpha stage will see INI or POT (wish is not POT selected, but will be better then existing) ?

Does anyone take the position and initiative to rewrite X 2.6 core language files ?

1. Profile must be wiped out and rewritten from scratch.
Except all bugs discovered so far in this black hole generator, there are tons of unfinished tasks.
During user registration (for English speakers is simple, I always means me (as male and/or female), but for rest languages there are 2-3 forms. There should be used/required field - Gender.
2. Joined / Registered - got 2 translations too based on Gender
2.1. Joined for male (got one translation in Bulgarian, Russian and several more languages), Joined for female - another.
3. The user based on gender:
3.1. User made %1 posts - got another translation for male and other for female
4. Time based statistics, avoiding to hard coding "ago", 5 minutes ago must be written as %1 minute ago and %1 minutes ago - there are different translation for single minute and for several minutes, also if is written into code, translation will look awful. 5 Minutes Ago is ok for US, not for the rest of the world, in Bulgarian is ago 5 minutes (well, not really with Latin alphabet, but in this order).
5. Social activities on site:
5.1. User %1 have downloaded %2, %3 time
5.1.1. User %1 have downloaded %2, %3 times
5.2 User %1 made %1 post in our forums
5.2.1. User %1 made %1 posts in our forums
and so on...
Replacing WEIGHT, STORY, DIGEST (need to download a nulled version of another US English written script, to see that this thing DIGEST is Newsletter, grrr) and few others strange words used only by hmm(censored) with local community rule/law!
Putting option for TEXT OVERRIDE for every piece of XOOPS in administration
Replacing default media/file management with Lucio's File Manager
Wiping and rewriting from scratch Blocks Administration
X25/6 is still the easiest Framework after the "most powerful, slowish, useless" J! 3.0 release. But there is a multifunctional easy to use and upgradeable Bridge plugin (http://www.jfusion.org), JFusion makes life easier - if u have idea to make site with the CMS, but currently the CMS don't have important feature u need such as forum (yay, X and J! don't have much options..... 1 forum per core, no choices), you can simply write plugin for the Bridging plugin and use MyBB, SMF or whatever u want.
-----
Mail Templates must be re/moved to SQL and to be made editable from Administration.
-----
Help must be moved to wiki.xoops.org
-----
(Can't wait to see redheaded Install script)
-----
After some tests during my vacation on latest CMS cores, including:
J! 3.0 Beta 1
XOOPS 2.6.0 Alpha 1
PinCore SVN
Tomato Cart 2 SVN
PresaShop 1.5 SVN

I've noticed some very funny bugs which should be avoided here.
Joomla! 3.0 works fine with GPC Magic Quotes On, but the stupid installation pre-check script prevent user to install it with On value in they're PHP.INI files.

X 2.6.0 Alpha 2, must includes option to ignore pre-check if one of the optional values such as GPC Magic Quotes is enabled or not.

PrestaShop 1.5 made a big progress in making administration easy to use, but, there is always but.

+ Single click module installation and auto-upgrade from the administration, but bcz there is lacking of MD5 or SHA1 checksum verification on modules, such installation can't be done properly, for RC2 - looking more like Alpha 2, is very disappointing result. Again... lack of coordination here, makes redheaded and wishcraft to work separately on different modules/frameworks for one simple task.

+ Making administration sorted (User tasks in one menu with several drop-down options), here as I saw users tasks are still in menus which no one expect to be there

+ TomatoCart/pincore - Windows XP still remains most used Desktop this days, and maintaining such administration style in X 2.6, will be a plus. The 2nd big advantage of this theme are the conflicts between Internet Exploder versions prior 9.0 SP1 with Ext JS library, if the user want to use Ext JS style have to switch to Firefox - and bye, bye Exploder - no more pointless threads on support forums regarding any part of the CMS which is not displayed properly thanks to damn MS Exploder.

+ "Responsive" Templates... err, themes here. Every core of the new CMSystems got one Responsive template for they're default administration/site view, which in one word - shows no difference in site/administration display on Chromium with Gentoo, Firefox with 7/8, Chrome on Android or Opera latest beta (don't remember which is latest 12.xx. beta) - http://www.newspaperwebdesign.com/node/15874

Main Dashboard of X26 should be full with statistics blocks, not with double information about installed modules. Eg. Registered Users, used system resources (specially when X is mostly used on shared hosting plans), made posts in any area - news, forums, top authors, users with most applauds or most warning and so on), why there are modules and tasks with big icons, and with small icons in header bellow menus, and again in menus.
PrestaShop 1.5 administration (if u want to see it and don't have time to install it, drop me PM) is a perfect example, how modern administration must look.

There are planed updates on TX (but still in development and tests), for GIT support for the Reviewed releases (eg, finished and reviewed for bugs translations).

X 26 Alpha 3-4, must support cURL and GiT for sync directly with translated, verified only modules, then the need of packing and listing them in several threads on forums here will gone. If Iranian (Farsi) user plans to use X26, News, NewBB, simply with one click from administration will be able to download and apply the required language files.

In past there was Lang_tool (XOOPS 2.0.18) written by Vietnamese or... can't remember right, but I'm 99% sure, he was an Asian developer, module which allows u to edit, correct, write new language files for core and any of the 3rd party installed modules, such option must exists first for the TEXT OVERRIDE option, 2nd... if the above Farsi user don't like something how looks translated to be able to correct it in the way he want for his site and needs.

....and DECISION which standard will be used, INI (1.5 or 2.5, or derivative mix of both), POT (yack, big sorry for all translators, bcz there is only 1 English native speaker as module developer, and is not Wishcraft) or PHP Define which will be a big step backward.

(In 5 days will update X Modules translations and will see if there are new core translations, just I'm still on road almost every day).

about images:
1- we have some icons like pdf, print, social networks that should be read from a unique location for all modules. so we cannot use css3 buttons for them.

2- Xoops should support both images and css3 for some images contain text like comments and forum buttons. I already do it for newbb 4.3. please test newbb 4.3 irmtfan SVN and see.

3- for css3 buttons we dont need to add new definitions. we have all definitions. eg: reply, edit, ... in newbb

Quote:
i hope soon.

Quote:
or at least take a deep look line by line and improve its performances in using cpu and memory.

Quote:

AFAIK, you can create a custom field and make it required in registration?

but it seems you want some other fields do a task based on changes on Gender field.
It is not possible in current profile module. If we have this feature in the future we can do many many things like conditional registering, conditional group showing and much much more.

Quote:
yes. i think it is already in sf.net feature request.

Quote:

Why not?
Isn't the use of sprintf() better then doing concatenations? I though this was recommended by all other cms.

Quote from wordpress
http://codex.wordpress.org/Translating_WordPress
Quote:

Hi Trabis
Im glad that you read this topic.
Among all subjects in this topic the issue you raised ("Formatting in PHP Definitions") is the least important one.
IMO all html formatting should be moved to templates/css/themes. so i think we all are agreed this should not be allowed anymore:


but you raised "Messages With Placeholders"
It is very minor issue. I just think about it. When i wrote that I meant we should not use either sprintf nor concatenations.

I think having separate constants are more customizable.

eg: in newbb now we have this:
newbb/index.php:

and in templates you just have this: <{$userstats.posts}>

but if we can separate it.



then a formatting lover can play with it in template:



Also just about this:
Quote:

I think the only advantage of using sprintf is its formatting capability? and when we dont want to use this advantage why we still should use this.

also concatenations are much faster than sprintf? (about 150%) am i wrong?

http://micro-optimization.com/string-concatenation-with-double-quotes-vs-sprintf
and this:
http://r.je/sprintf.html

EDIT:
one more thing.
many of our current translators have a very basic php knowledge.
missing a %s in definition is a most common error in our local translations.(persian is RTL and latic characters like %s inside a string will make it hard for translators)
Also there is not that WP standard in XOOPS to have %1$s, %2$s, %3$s,... in definitions.
A developer just use what he preferred for example 12 %s in one definition so i cannot blame the poor translator for his fault!!!

Quote: Sorry for raising this issue, but I agree with the others, just not this one. I agree with the above example. Html formatting should be done on templates/css. Quote: The above examples do not use keys and are not translatable(only directly in file). They do not call any function to do a translation. $str = 'Hi ' . $name . ', you last logged in on ' . $date; They are faster but do not have appliance in a translatable project. Now, with translate calls, would this be good for you? $str = _('HI') . $name . ', ' . _('YOU_LAST_LOGGED_IN_ON') . $date; Aren't we forcing translators to use a rule established by the code developer? What if translator wants to greet the user after giving the logged in date? Look at the absurd: $str = _('HI') . $name . _('COLON') . _('SPACE') . _('YOU') . _('SPACE') . _('LAST')..... We should translate expressions, not single words. Concatenations are a work for translators. Imagine if google translated word by word not regarding the context. Also notice that every time we call a function we are impacting performance. Using concatenations will produce more calls, more time spent. Quote: We can change that!

Quote:

From bad to worst (Nuke to WP), let's make it like Drupal, it's a solid-rock CMS which no one use from ages, the only CMS which uses NODE instead of Article, well 2nd using Weight instead of Ordering, Taxonomy Term for Sub-category, and adding GNU Gettext.

Alpha 2 is coming out soon without setting up important things....
The user is user without Gender only in English, in rest languages there are... (3 forms) "I accept ToS" - don't have other meaning then I (but for English only, when female/male/boy accepts terms).

Then forms:
X-1.0.zip downloaded %1s (one download)
X-1.0.zip downloaded %2s (many downloads)

Forum (User)
User (Gender type) have %s (Male/Female got same translation here, but different on count)
User (Gender type) have %s

Female/Male quote:
Alesia wrote: (got one translation for Female)
Alex wrote: (got another translaton for Male)

(but not and same words are used for system)
Forum (System)
Forum (system) have %s post
Forum (system) have %s post

2nd point - no idea what for will be used as language files, INI, POT, PHP or something else ? How much alphas will go out ?

3rd.....
Several different threads are opened for 2.6 without mentioning simple task tree:

ACL - 0% done or 100%, current ACL used in 2.5 not allows to make administrator for specific module operations, for example can approve downloads, can create categories, can upload, can operate in specific categories, but can't delete....
i10n - 0% done for sure
Users - 0% done for sure
Content - xxx% done ?!?
etc, etc.
Quote:

How the decision was taken for this ? XOOPS was "community driven", where was the Poll regarding all alternatives ? I think something like this was used in J! 1.0 and removed by own class in 2.5, so the users can make PDF of any content type from the sites in Cyrillic.

Quote:

This means nothing - content like the default option in Baned CMS ? Wow if is this, amazing, just amazing....

Quote:

Simple Menu Manager or something like Solo Menu module ?

File Manager/Image Manager ? Maybe in Alpha 5 on random pick without votes ?
Content/Blocks editor - SC, tinyMCE (yack), CK, default used in XOOPS 2.5 ?

Alpha 3 looks like Beta 1
And Final 2.6.0 around Christmas 2013 or Q2 of 2014.... (but better late, then never )

Won't mention my favorite - Sign up/in, Weight and a lot of other termins not used anywhere else except in Drupal/XOOPS 2.5/WP, which making system not only "non-user friendly" but also not understandable...