Why can't you count on JText being available? This is in the joomla
platform, where JText IS available. If you're talking about for long term -
are there plans to deprecate JText? If so, what is going to be used for
translations of interface elements and language within the platform / cms?
The goal is to separate the packages to leave as few dependencies as
possible. If JText were used for all of the exceptions, then you would
always require the Language package from the platform. For the project
you're building, you may not need it.
From: Donald Gilbert <dilbert4l...@gmail.com>
Reply-To: <joomla-dev-platform@googlegroups.com>
Date: Monday, October 1, 2012 8:26 AM
To: <joomla-dev-platform@googlegroups.com>
Subject: Re: [jplatform] Re: what is the better way of generating an
Exception Message?
Why can't you count on JText being available? This is in the joomla
platform, where JText IS available. If you're talking about for long term -
are there plans to deprecate JText? If so, what is going to be used for
translations of interface elements and language within the platform / cms?
I guess a good example would be the upgrade check application I built to
help check system requirements for CMS 3.0.
https://github.com/mbabker/J30UpgradeCheck/tree/master/libraries Notice
how there's a lot of folders missing from the cms, joomla, and legacy trees.
I removed everything that I didn't need to make this package as light-weight
as possible.
From: Michael Babker <mbab...@flbab.com>
Reply-To: <joomla-dev-platform@googlegroups.com>
Date: Monday, October 1, 2012 8:28 AM
To: <joomla-dev-platform@googlegroups.com>
Subject: Re: [jplatform] Re: what is the better way of generating an
Exception Message?
The goal is to separate the packages to leave as few dependencies as
possible. If JText were used for all of the exceptions, then you would
always require the Language package from the platform. For the project
you're building, you may not need it.
From: Donald Gilbert <dilbert4l...@gmail.com>
Reply-To: <joomla-dev-platform@googlegroups.com>
Date: Monday, October 1, 2012 8:26 AM
To: <joomla-dev-platform@googlegroups.com>
Subject: Re: [jplatform] Re: what is the better way of generating an
Exception Message?
Why can't you count on JText being available? This is in the joomla
platform, where JText IS available. If you're talking about for long term -
are there plans to deprecate JText? If so, what is going to be used for
translations of interface elements and language within the platform / cms?
Ok, but the point of a platform is how well the pieces work together. I can
understand decoupling JText, since you may or may not need it if you use
the platform for something besides the CMS, but what then are you going to
use for translations?
How far does this goal reach? Removing all class inter-dependency within a
development platform seems ludicrous to me, because it (very often) breaks
the DRY principle.
All of the exceptions were converted to static text. This ensures that the
message isn't dependent on a language string being available. If my project
doesn't need translations, then it's as simple as not including the Language
package (if all other dependencies are broken from it). If I need
translations, I'll use the Language package and JText since it's a tested
system and works.
As far as breaking all dependencies, I doubt it will happen. But where
other solutions are available, we're moving in that direction. There's been
a few commits to the Platform replacing calls to JFile::exists with PHP's
native is_file, for example. Some things are simple to replace, others need
some work. In the end though, I think it will improve the overall code
quality of the Platform.
From: Donald Gilbert <dilbert4l...@gmail.com>
Reply-To: <joomla-dev-platform@googlegroups.com>
Date: Monday, October 1, 2012 8:42 AM
To: <joomla-dev-platform@googlegroups.com>
Subject: Re: [jplatform] Re: what is the better way of generating an
Exception Message?
Ok, but the point of a platform is how well the pieces work together. I can
understand decoupling JText, since you may or may not need it if you use the
platform for something besides the CMS, but what then are you going to use
for translations?
How far does this goal reach? Removing all class inter-dependency within a
development platform seems ludicrous to me, because it (very often) breaks
the DRY principle.
Just to follow up on what Niels and Michael have said here, the direction
is not to copy/paste code all over the place un-DRY-ing everything. The
idea is that separate parts should be separate. Quite a bit of the
platform was written to bridge gaps in PHP. Either bridging from PHP4 to
PHP5 (eg. JObject, JSimpleXML) or just filling in things we found as holes
here and there. In a few places we tried to bridge the gap between PHP
installations such as JFTP, which is designed to use the native FTP methods
if present and fall back on our own implementation if they are not present.
Not all hosts have the FTP extension installed, and we felt it was
necessary at the time to make things less painful for lots of new users.
As these things become less necessary we will re-evaluate their lease on
life.
With respect to Exception messages, I am strongly against having
translation within those messages. The reality of the situation is that
exception messages are for developers, not users. A well built application
will catch exceptions, inspect them, and then either direct or message the
user gracefully. As pointed out we don't know if the exception may have
occurred within the mechanism to translate the message, or some dependency
of that translation mechanism. As a project we are certainly committed to
internationalization and localization, but I don't see the reward vs the
risk on translating exception messages ... especially at the point where
they are thrown.
Lastly, with respect to separation of platform packages, this is something
we want to work towards. It isn't an absolute, but it is a principle.
Similarly, DRY is a principle. Sometimes it is just insane not to repeat
a block of code somewhere else. Other times it is insane to do so. One of
our goals is to build the platform in such a way that we can only select
the packages we actually need for a project. We'll continue to work
towards that end, and also continue to work towards not repeating
ourselves. When those two principles conflict we will have to assess, make
a judgement call, and move forwards.
On Mon, Oct 1, 2012 at 9:44 AM, Michael Babker <mbab...@flbab.com> wrote:
> All of the exceptions were converted to static text. This ensures that
> the message isn't dependent on a language string being available. If my
> project doesn't need translations, then it's as simple as not including the
> Language package (if all other dependencies are broken from it). If I need
> translations, I'll use the Language package and JText since it's a tested
> system and works.
> As far as breaking all dependencies, I doubt it will happen. But where
> other solutions are available, we're moving in that direction. There's
> been a few commits to the Platform replacing calls to JFile::exists with
> PHP's native is_file, for example. Some things are simple to replace,
> others need some work. In the end though, I think it will improve the
> overall code quality of the Platform.
> From: Donald Gilbert <dilbert4l...@gmail.com>
> Reply-To: <joomla-dev-platform@googlegroups.com>
> Date: Monday, October 1, 2012 8:42 AM
> To: <joomla-dev-platform@googlegroups.com>
> Subject: Re: [jplatform] Re: what is the better way of generating an
> Exception Message?
> Ok, but the point of a platform is how well the pieces work together. I
> can understand decoupling JText, since you may or may not need it if you
> use the platform for something besides the CMS, but what then are you going
> to use for translations?
> How far does this goal reach? Removing all class inter-dependency within a
> development platform seems ludicrous to me, because it (very often) breaks
> the DRY principle.
I have no issue with not translating Exception messages.
What would be handy though is to get regularly the list of JLIB strings we can safely take off from the .ini files.
This would greatly help new Transators as they would not have to translate these.
>Just to follow up on what Niels and Michael have said here, the >direction is not to copy/paste code all over the place un-DRY-ing >everything. The idea is that separate parts should be separate. > Quite a bit of the platform was written to bridge gaps in PHP. > Either bridging from PHP4 to PHP5 (eg. JObject, JSimpleXML) or just >filling in things we found as holes here and there. In a few places >we tried to bridge the gap between PHP installations such as JFTP, >which is designed to use the native FTP methods if present and fall >back on our own implementation if they are not present. Not all >hosts have the FTP extension installed, and we felt it was necessary >at the time to make things less painful for lots of new users. As >these things become less necessary we will re-evaluate their lease >on life.
>With respect to Exception messages, I am strongly against having >translation within those messages. The reality of the situation is >that exception messages are for developers, not users. A well built >application will catch exceptions, inspect them, and then either >direct or message the user gracefully. As pointed out we don't know >if the exception may have occurred within the mechanism to translate >the message, or some dependency of that translation mechanism. As a >project we are certainly committed to internationalization and >localization, but I don't see the reward vs the risk on translating >exception messages ... especially at the point where they are thrown.
>Lastly, with respect to separation of platform packages, this is >something we want to work towards. It isn't an absolute, but it is >a principle. Similarly, DRY is a principle. Sometimes it is just >insane not to repeat a block of code somewhere else. Other times it >is insane to do so. One of our goals is to build the platform in >such a way that we can only select the packages we actually need for >a project. We'll continue to work towards that end, and also >continue to work towards not repeating ourselves. When those two >principles conflict we will have to assess, make a judgement call, >and move forwards.
>I hope that helps.
>- Louis
>On Mon, Oct 1, 2012 at 9:44 AM, Michael Babker ><<mailto:mbab...@flbab.com>mbab...@flbab.com> wrote:
>All of the exceptions were converted to static text. This ensures >that the message isn't dependent on a language string being >available. If my project doesn't need translations, then it's as >simple as not including the Language package (if all other >dependencies are broken from it). If I need translations, I'll use >the Language package and JText since it's a tested system and works.
>As far as breaking all dependencies, I doubt it will happen. But >where other solutions are available, we're moving in that direction. > There's been a few commits to the Platform replacing calls to >JFile::exists with PHP's native is_file, for example. Some things >are simple to replace, others need some work. In the end though, I >think it will improve the overall code quality of the Platform.
>From: Donald Gilbert <<mailto:dilbert4l...@gmail.com>dilbert4l...@gmail.com>
>Reply-To: ><<mailto:joomla-dev-platform@googlegroups.com>joomla-dev-platform@googlegr oups.com>
>Date: Monday, October 1, 2012 8:42 AM
>To: ><<mailto:joomla-dev-platform@googlegroups.com>joomla-dev-platform@googlegr oups.com>
>Subject: Re: [jplatform] Re: what is the better way of generating an >Exception Message?
>Ok, but the point of a platform is how well the pieces work >together. I can understand decoupling JText, since you may or may >not need it if you use the platform for something besides the CMS, >but what then are you going to use for translations?
>How far does this goal reach? Removing all class inter-dependency >within a development platform seems ludicrous to me, because it >(very often) breaks the DRY principle.
--
>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
