Decoupling platform language files from CMS

[piotr_cz]

Joomla Platform is using JText probably in all of it's packages, but
language files belong to CMS at the moment.

To use it, one has to Install Joomla CMS, than desired language
package and copy some files to application that's running on the
platform.

Besides library language file ($lang.lib_joomla.ini) is not being
loaded by default during JApplicationWeb->initialise; only
$lang.joomla.ini and $lang.localise.php are.

$lang.joomla.ini language strings are being used by
- JDate,
- JDocument,
- JFolder->move,
- JForm fields,
- JHtml classes, JLanguate,
- JPagination

All other packages are using $lang.lib_joomla.ini

I'd like to see all strings used by library moved to library language
file and maybe having two separate language packages (CMS language
package containing library file).

But I'm aware this is very delicate thing given the amount of
tranlation teams and coordinating such change.


My questions are:

Are there any other people interested in such decoupling, does it it
bring enogh advantage to do so?
How would we do it?
What are current recommendations on installing language in platform?

[Andrew Eddie]

The short answer is we should not be using JText in the platform unless absolutely necessary. I think the easiest way to proceed is to take a few examples and ask about what to do.

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - free tutorials and videos on Joomla development

--
You received this message because you are subscribed to the Google Groups "Joomla! Platform Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-plat...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[piotr_cz]

My example:
I decided to use Platform to create simple website (3 pages).
One of the pages is contact form, so I used a JForm.
When testing server-side validation I got some untranslated JText
strings and that's where I decided to check on JText usage in platform
and add language functionality.

JText is used in 14 of 42 packages.

There's Joomla Platform and Joomla CMS.
It's very convenient to install language packages to CMS, but I'm not
what are the recommended steps for Platform.

On Feb 24, 1:12 pm, Andrew Eddie <mambob...@gmail.com> wrote:
> The short answer is we should not be using JText in the platform unless
> absolutely necessary. I think the easiest way to proceed is to take a few
> examples and ask about what to do.
>
> Regards,

> Andrew Eddiehttp://learn.theartofjoomla.com- free tutorials and videos on Joomla
> development

[Andrew Eddie]

Yeah, JForm is one place we will need to be careful but otherwise we need to convert everything back to natural language string. It's probably better to put that effort into the Framework (because if the Platform gets absorbed back into the CMS it's not an issue).

I've created an issue for that if you want to help out or ask questions.

https://github.com/joomla/joomla-framework/issues/22

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - free tutorials and videos on Joomla development

[Amy Stephen]

I don't know if this will help, or not, but if you don't care about the translations, an easy way to deal with this is to create a "dummy" JLanguage Class with the "__" method that simply returns the value sent in. (going from memory, there could be another method, or two, needed.)

At least it moves the issue out of the way, even if it doesn't take care of the translation.

[Amy Stephen]

JText class - not JLanguage.

[Andrew Eddie]

On 1 March 2013 14:30, Amy Stephen <amyst...@gmail.com> wrote:

JText class - not JLanguage.

That won't help is the value passed is a language key?

Regards,

Andrew Eddie

[JM Simonet]

Me worry.

How can we merge platform stuff in CMS if the platform does not use JText and our ini files?

ATM xx-XX.lib_joomla.ini contains 639 lines.

JM

-- 

Please keep the Subject wording in your answers

This e-mail and any attachments may be confidential. You must not disclose or use the information contained in this e-mail if you are not the
intended recipient. If you have received this e-mail in error, please notify us immediately and delete the e-mail and all copies.

-----------------------------------------------------------

Jean-Marie Simonet  /  infograf768

Joomla Production Working group

Joomla! Translation Coordination Team 

[Andrew Eddie]

On 1 March 2013 17:37, JM Simonet <infog...@gmail.com> wrote:

Me worry.

How can we merge platform stuff in CMS if the platform does not use JText and our ini files?

ATM xx-XX.lib_joomla.ini contains 639 lines.

We are only going to do this in the Framework. The CMS is going to go back to just maintaining /libraries itself so you can keep all the language strings if you want.

Regards,

Andrew Eddie 

[piotr_cz]

Isn't the plan that /libraries/joomla == joomla-framework packages?
still confused

What if the JText is left as is, but there's always an english fall
back string provided.
JText::_('JLIB_USER_ERROR_PASSWORD_NOT_MATCH', 'Passwords do not
match. Please re-enter password.' );

Maybe it could be automated that the fallback is pulled from current
'en-GB.lib_joomla.ini' on every build.

Oh, wait, there should't be need to build separate packages,
right ? :)


On Mar 1, 8:42 am, Andrew Eddie <mambob...@gmail.com> wrote:
> On 1 March 2013 17:37, JM Simonet <infograf...@gmail.com> wrote:
>
> > **

[Andrew Eddie]

On 1 March 2013 19:50, piotr_cz <pkoni...@hotmail.com> wrote:

Isn't the plan that /libraries/joomla == joomla-framework packages?
still confused

Ok. Currently we have the Joomla Platform and we tag versions of that.

The CMS the selects a tagged version of the Platform and copies it under /libraries/joomla

Because namespacing is going to generate too much pain for the CMS, we are proposing that we drop the Joomla Platform, and the CMS maintains the files under /libraries/joomla (just like we did back in the 1.5 and 1.6 days).

The Joomla Framework is going to be individually installable packages (usually via Composer) and they are all going to be namespaced. We are also going to strip out all the remaining code that is only useful for the CMS, because it won't be useful to the rest of the PHP community, nor developers wanting to build new applications on the Framework.

Now, someday in the future the CMS might decide it's time to think about namespacing, or they might see another package they want to use. They can then include that at their leisure, and because the package is namespaced, it causes no conflict with existing code. In hindsight, it's how we should have handled the new MVC, but it is what it is. 3.2 or 3.5 might be a good time to think about making some changes, but certainly Joomla 4.x should think about using Composer and the Joomla Framework (that's my opinion anyway).

So, in a few months, we won't have any Joomla Platform repo, we will just have people contributing to the Joomla CMS and to the Joomla Framework.

Does that help?

 

What if the JText is left as is, but there's always an english fall
back string provided.
JText::_('JLIB_USER_ERROR_PASSWORD_NOT_MATCH', 'Passwords do not
match. Please re-enter password.' );

That's double handling.

 

Maybe it could be automated that the fallback is pulled from current
'en-GB.lib_joomla.ini' on every build.

Oh, wait, there should't be need to build separate packages,
right ? :)

 en-GB.lib_joomla.ini only exists in the CMS. Language files are not included with the Platform today and we don't plan to add them to the Framework. The application should decide how that is handled. Having said that, we still have to work out how to handle the Form package. I think we will end up splitting it up - but I'm not completely sure yet. I need to sleep on some more :)

Regards,

Andrew Eddie

[Amy Stephen]

JM - this is not related to the CMS, at all. In fact, this challenge is only related to when the CMS is not involved. The Language system is very tightly coupled to the CMS.

I had understood piotr_cz to ask how to uncouple JText from the platform - to basically ignore it for now. So, my answer was intended as a quick, short-term work around, if you wanted to take a subsystem, but not the entire platform, and avoid the dependency, but don't want to hack JText out, just create a little class that passes back the value sent in. Done. (Ignores it.)

The long term solution is different and that's going to take a little thought to keep it open and possibly be able to use other language solutions. I've not looked too much for solutions but I believe using brackets {translate this} and parsing rendered output is how many keep the translation uncoupled from the packages.

[Michael Babker]

For what it's worth, I personally support leaving JText as a dependency in classes that render output for users, i.e. JForm.  In places where messages are queued into a log, I fully support decoupling JText in preference to natural language.

--

You received this message because you are subscribed to the Google Groups "Joomla! Platform Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-plat...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
- Michael

Please pardon any errors, this message was sent from my iPhone.

[piotr_cz]

Thank you for taking time to explain it, indeed this helps a lot.

On Mar 1, 11:03 am, Andrew Eddie <mambob...@gmail.com> wrote:

[piotr_cz]

To be clear: I started this thread not because I was thinking about
getting rid of JText in Platform, but because Platform is using both
en-GB.lib_joomla.ini (okay) and en-GB.ini (wrong) and I didn't know
about recommended way to install these into application based on
Platform.


Anyway when thinking about it now, maybe it makes sense to evaluate
all JText uses (shouldn't be there an Exception/ JLog entry instead)?

On Mar 1, 6:29 pm, Michael Babker <michael.bab...@gmail.com> wrote:
> For what it's worth, I personally support leaving JText as a dependency in
> classes that render output for users, i.e. JForm.  In places where messages
> are queued into a log, I fully support decoupling JText in preference to
> natural language.
>
>
>
>
>
>
>
>
>
> On Friday, March 1, 2013, Amy Stephen wrote:
> > JM - this is not related to the CMS, at all. In fact, this challenge is
> > only related to when the CMS is not involved. The Language system is very
> > tightly coupled to the CMS.
>
> > I had understood piotr_cz to ask how to uncouple JText from the platform -
> > to basically ignore it for now. So, my answer was intended as a quick,
> > short-term work around, if you wanted to take a subsystem, but not the
> > entire platform, and avoid the dependency, but don't want to hack JText
> > out, just create a little class that passes back the value sent in. Done.
> > (Ignores it.)
>
> > The long term solution is different and that's going to take a little
> > thought to keep it open and possibly be able to use other language
> > solutions. I've not looked too much for solutions but I believe using
> > brackets {translate this} and parsing rendered output is how many keep the
> > translation uncoupled from the packages.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Joomla! Platform Development" group.
> > To unsubscribe from this group and stop receiving emails from it, send an

> > email to joomla-dev-plat...@googlegroups.com<javascript:_e({}, 'cvml',
> > 'joomla-dev-platform%2Bunsu...@googlegroups.com');>.
> > For more options, visithttps://groups.google.com/groups/opt_out.

[Donald Gilbert]

IMO we need to provide an easier way for devs using JForm to override the markup that is generated, which would, in this case, also include the ability to translate strings in that overridden markup.

My 2 cents.

[Amy Stephen]

On Friday, March 1, 2013 11:29:42 AM UTC-6, Michael Babker wrote:

For what it's worth, I personally support leaving JText as a dependency in classes that render output for users, i.e. JForm.  In places where messages are queued into a log, I fully support decoupling JText in preference to natural language.

should be able to inject those