@Mamba:
I think you misunderstood me.
I dont want to move translations from "modules/MODULE/language" folder to "themes" folder. I want to provide
extra functionality for customizationIt means you can have your old method for translations as a module developer or translator but also you will have the chance to create different translations for each theme.
IMO Xoops should provide a mechanism that all "front side" customizations (that currently we are doing in different places like language folder of every module) would be implemented inside "themes" folder.
for example for xhelp module the priority for parsing translations would be:
1- IF EXISTS themes/YOUR_THEME/modules/xhelp/language/, TAKE IT;
2- ELSEIF EXISTS themes/default/modules/xhelp/language/, TAKE IT;
3- ELSE TAKE XOOPS_ROOT/modules/xhelp/language/
In current system in 2.5.5/2.6 we just have third option.
IMO it is beauty, very easy and simple with legacy support while open new doors for theme designers.
As i said in the last post it can be done for all "front side" files like images/icons/js/css
It has been done in newbb recent versions for images/icons and i enhanced it in "irmtfan branch" for css and js too.
My designer is really happy with it because he can build a "newbb independent template set" for each theme.
in current newbb version all these files are inside "modules/newbb/templates" folder (eg: modules/newbb/templates/css) but if you dont like that they can be inside the MODULE root as before for legacy support. (I see in 2.6 core developers put the media files in module root)
eg: newbb/language, newbb/images, newbb/icons, newbb/css and newbb/js
one can change that place easily.
the place of these files inside the MODULE
is not important at all. Just we need to decide about a standard location. Only provide that customization functionality in "themes" folder is important.
@ Trabis:
Any system can provide those features in my last post is OK in my point of view.
Only at a first glance it seems it is hard for beginners to do that class method for their local languages unless they could do it with a GUI language tool.
I will test that class.
Edit:
Ok i test it.
I still cannot understand this:
Quote:
If a constant is missing, the parent class will provide the constant.
You said it cannot load 2 XoopsLocale class. then how it can parse missing constants in another language?
eg in pt that you mentioned lets say one constant is missing:
class ModuleLocaleEn {
const MODULE_NAME = 'My module';
const MODULE_DESC = 'My module description'; // irmtfan
}
and in pt:
class ModuleLocalePt {
const MODULE_NAME = 'O meu módulo';
}
can MODULE_DESC be parsed in pt?
Edit2:
maybe you could do this? in module/pt/pt.php
include_once '../en/en.php';
class ModuleLocalePt extends ModuleLocaleEn{
const MODULE_NAME = 'O meu módulo';
}