Feature proposal #4528
Updated by nant almost 10 years ago
h1. Introduction
With Community Builder 2.0 the language support mechanism is being redesigned to move away from the legacy DEFINE statements that existed in the language.php files of CB Language plugins.
h1. New Default Language File Structure
The default language files in CB 2.0 are located in:
{Joomla_root}/components/com_comprofiler/plugin/language/default_language
This folder contains the following:
# language.php (frontend default language definitions in PHP array format)
# admin_language.php (administrator area language definitions in PHP array format)
# default_language.xml (?)
# index.html (?)
# images folder (?)
+Confirmation Question:+
Has the Javascipt calendar-locals.js file been migrated?
The language.php and admin_language.php files also contain all strings for all CB related add-ons that are installed with CB 2.0.
+Question:+
What about language strings for the modules (login, online, workflow) and the new Admin Navigation module and the redirect plugin?
+Question/Issue:+
We need to decide how these CB interacting Joomla extensions are translated and how we manage the translation projects?
It looks like we will be dealing with a mix of ini files and php files. Transifex can handle different resource types in the same project, so in theory we could have a single CB Language plugin that also has ini files in it and during installation these can be moved/copied to the proper Joomla language folders.
h1. New CB Language Plugin Concept
Extra language support for CB will be handled with the installation of CB Language plugins via the CB Plugin Installer.
h2. New CB Language Plugin structure
The contents of a CB Language plugin package are:
# language.xml
# language.php
# admin_language.php
# images (folder and contents)?
# index.html (?)
h3. The language.xml contents
The structure of the language.xml file conforms to the following sample:
TO-BE-PROVIDED (Kyle, can you give an example here?)
h3. The language.php and admin_language.php files
This is an array based php file that contains language translations in the format:
@return array(
'KEY_1' => 'Translation for this string',
...
);@
h2. CB Language plugin installation actions
When a CB Language plugin is installed using the CB Plugin Manager the following actions take place:
# A new folder named xx-yy (iso language code taken from the language.xml contents) is created in the components/com_comprofiler/plugin/language folder (same level as the default_language folder)
# The language.php, admin_language.php, language.xml, ini files (?) and images folder with contents (?) are copied to the xx-yy folder
+Question/Issue:+
If we do decide to include Joomla ini files in our CB Language packages, we need to decide if we need to copy these over to the Joomla language areas.
h1. Extra CB add-ons and their language support
A CB Plugin should contain its own default_language folder with its language.php, language.xml, language.xml, ini (?) files, images (?).
This default_language folder (and also other language folders that may be included in the initial add-on distribution) should be located in the:
plugin/user/plug_name/languages/ folder,
When installing a CB add-on the default_language contents supporting this plugin are copied to the:
plugin/language/default_language/plug_name folder
+Question/issue:+
Some CB add-ons (see CBSubs and GroupJive and CB Activity) have Joomla modules so in theory they need ini files. How should we support such a case?
h1. Overall Picture
Lets assume that we have CB 2.0 installed and we have also installed its en-gb language plugin.
In addition lets assume that we have installed the new CB GroupJive add-on (plug_cbgroupjive) that includes its own default_language and en-gb language support in its distribution package.
The following folder/file structure should be in place:
+Community Builder installed languages+
@compnents/com_comprofiler/language:
default_language/ en-gb/@
+Community Builder default_language structure with installed plug_cbgroupjive support+
@compnents/com_comprofiler/language/default_language:
plug_cbgroupjive/ language.xml language.php admin_language.php images/ ini_files?@
+Default language supprt for plug_cbgroupjive+
@compnents/com_comprofiler/language/default_language/plug_cbgroupjive:
language.xml language.php admin_language.php ini_files(?) images(?)/@
+Community Builder English language support (after installation of CB English language pack and Groupjive add-on)+
@compnents/com_comprofiler/language/en-gb:
plug_cbgroupjive/ language.xml language.php admin_language.php images/ ini_files?
@
+English language support for Groupjive in CB english flder structure+
@compnents/com_comprofiler/language/en-gb/plug_cbgroupjive:
language.xml language.php admin_language.php ini_files(?) images(?)/@
+Groupjive language local plugin structure+
@components/com_comprofiler/plugin/user/plug_cbgroupjive/language:
default_language/ en-gb/@
+GroupJive local plugin default_language structure+
@components/com_comprofiler/plugin/user/plug_cbgroupjive/language/default_language:
language.xml language.php admin_language.php ini_files(?) images(?)/@
+GroupJive local plugin en-gn language structure+
@components/com_comprofiler/plugin/user/plug_cbgroupjive/language/en-gb:
language.xml language.php admin_language.php ini_files(?) images(?)/
@
h1. Transifex Related
On Transifex we currently have 3 projects for our translations:
# Community Builder
# GroupJive
# CBSubs
We do not have any projects for other add-ons.
The Community Builder project currently has the cbteamplugins_language.php resource which will be depreciated (as I understand it) and instead we will create additional Transifex projects for each of out non-core plugins.
These Transifex plugins will feed and area in our gitlabs (and maybe a mirror area on github?) that will serve as a repository that will be used to automatically generate (daily build?) a single (?) CB Team add-ons plugin package for each language that will contain translations for all our extra add-ons.
+Question/Issue:+
The xml file of this single package needs to be defined.
+Question/Issue:+
Should we also have a single multi-language plugin creation process? Example: create a CB All-Languages plugin that grabs translations from all Language teams for the CB project and creates a single installable plugin that will support all languages (not even sure how this would be handled - just bringing it up for discussion).