Joomla translation file format

[Hannes Papenberg]

Hello folks,
one of the issues still on our ToDo-list on the road to Joomla! 1.6 Beta
is the improvement in the area of the translation files. Currently,
parsing the INI-files for each page takes up to 25% of the overall
rendering-time and quick tests show that we can reduce this by 95% by
using native PHP functions instead.

In the last discussion about this on the list, we encountered possible
issues with bugs in PHP, which would make this more complicated and
maybe even force us to go back to custom written parsing functions. In
the light of these rumours, we thought about alternative ways to handle
the translation of Joomla, like using JSON encoded strings in the files
instead of INI strings or maybe even constants or similar. This again
made the translators grumpy. (Hello JM. ;-) ) To find a solution, I
planned on having the interested people come together in a chat and then
battle over this until developers, users and especially translators were
satisfied with the result. I actually already started writing the
invitation to that IRC chat, when I stopped and first wanted to take a
look again at the INI problems.

INI-files would actually be pretty good for the job, since they are
easily edited, we can namespace them and the changes necessary to our
current system are pretty small compared to moving to JSON or maybe even
a compiled format. So I looked at the reported issues, but I couldn't
really confirm all of them. I especially couldn't confirm those issues
that would be game-breakers to us to use it for the translations. I
wanted to test the different issues and compiled a little package which
I hope covers most of the problems that could come up. This test works
on my computer, however I just have PHP 5.2.8 and apparently the
function in question was changed from 5.2.0 to 5.3.1 at least twice and
it seems as if this was also OS dependent. This means that we need a few
people testing this on their (more diverse) systems.

If all tests return a positive result, the translation files in 1.6
would look something like this:
[CORE]
STRING1="Some translated String"

[COM_MEDIA]
PICTURE="Some picture string"

[COM_USER]
HELLO_USER="Hello "QUOTE"User"QUOTE" <--- returns 'Hello "User"'

and the function calls in Joomla itself could look like this:
echo JText::_('core.string1');

But before we can use this, we need to be sure that this function will
work on all systems out there supported by us. For this, I'd like us to
test this at least on a PHP =<5.2.3, a PHP >=5.2.8 and a PHP >=5.3.0 and
at least on Windows, Ubuntu 8.10, Ubuntu 9.10, another Linux
distribution and Mac. All this with the Apache server. I'd preferably
have an IIS in there, too, just to be sure. To test this, just unzip the
content of the attached zip-file into a folder of your webroot of your
webserver installation and open the test.php file in your browser. You
should get a table with different characterstrings, which should match.
I used greek, russian and chinese characters. If you only see ? or
squares, you don't have the proper fonts installed for that language. If
it works and especially if it doesn't work, post your OS, your server
(Apache, IIS, Lighttpd) and especially your PHP version back in this thread.

I also would like to hear your opinion on the testpackage itself. Did I
miss anything? Do we need to extend this check?

This is a pretty important improvement, so I would be really happy if
you could help out with this. :-)

Looking forward to the results of this test.

Hannes

[infograf768]

Windows XP Pro WAMP PHP 5.3 = OK
Macintosh Tiger 10.4.11 Apache native PHP 5.2.11 = OK
Macintosh Tiger 10.4.11 MAMP PHP 5.2.11 = OK
Ubuntu 9.04 PHP 5.2.6 = OK

More coming...

>  ini_test.zip
> 1KViewDownload

[infograf768]

Windows7_64 + Apache 2.2.11 + PHP 5.2.9-2 - Works good
CentOS 5 + Apache 2.2.14 + PHP 5.2.11 - Works good

Windows XP :
PHP 5.2.1
PHP 5.2.3
PHP 5.2.9
PHP 5.2.11
PHP 5.3.0
PHP 5.3.1
= ALL OK

Linux Kernel version 2.6.18-164.9.1.el5 PHP 5.2.11 - OK

[infograf768]

Mac OSX Snow Leopard + PHP 5.2.11 = OK

[Chris Davenport]

Test passed.

Ubuntu 9.10
PHP 5.2.10-2ubuntu6.3
Apache 2.2.12 (Ubuntu)

Regards,
Chris.

2010/1/5 infograf768 <infog...@gmail.com>

--

You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To post to this group, send an email to joomla-dev...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-frame...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-framework?hl=en-GB.

[Mostafa Alavi Nik]

Hello jean

please include also local js date into language files

thanks

[infograf768]

CentOS 5.0 PHP 5.2.12 = OK

On 5 Jan, 17:09, Chris Davenport <chris.davenp...@joomla.org> wrote:
> Test passed.
>
> Ubuntu 9.10
> PHP 5.2.10-2ubuntu6.3
> Apache 2.2.12 (Ubuntu)
>
> Regards,
> Chris.
>

> 2010/1/5 infograf768 <infograf...@gmail.com>

> > joomla-dev-frame...@googlegroups.com<joomla-dev-framework%2Bunsu...@googlegroups.com>

[infograf768]

FreeBSD 6.4-RELEASE-p7 #0 PHP 5.2.4 = OK

[El KuKu]

OpenSuSE 11.1
Apache 2.2.6
PHP 5.2.4

passed

>  ini_test.zip
> 1KViewDownload

[Christophe Demko]

Fedora 11. Kernel 2.6.30.10-105
Apache/2.2.13 (Unix)
PHP 5.2.11

passed

[Andrew998]

OS: Redhat Linux
Server: Apache/2
PHP: 5.2.11

Works fine.

[Manoel]

Expected = Actual

Apache 2.2.8 (Unix)
PHP 5.2.5

[Beat]

Just a small note: Even faster would be to use native PHP arrays for
language strings instead of INI files, as those would stay cached in
APC or other PHP caches between pages...

(yes it has a few drawbacks, but also quite a few advantages as well)

But that's not a change for 1.6, as we want 1.6 out soon :-)

Beat
http://www.joomlapolis.com/

>  ini_test.zip
> 1KViewDownload

[Hannes Papenberg]

Hi folks,
thank you all for your help. That was actually pretty fast, I didn't
expect you all to respond so fast. Its good to know that our community
is so responsive to all of this. :-)

So far the results look great and I started working on implementing
these changes in a "jtext" branch. The INI files still need to be
finished and quite a few keys need to be corrected, too, but for the
backend control panel it already works and, damn, its fast. Without much
improvements, we've got a performance gain of about 30% on my laptop. :-)

Please take a look at the changes in JLanguage and comment on it. I'll
try to write some documentation for the INI format and our future
translation files and then hopefully we can tackle this all together.

I hope you are feeling how excited I am about this great improvement. :-)

Hannes

[Marcos Peebles]

Apache 2.2.11 // Windows XP pro

PHP 5.2.0
PHP 5.2.1
PHP 5.2.2
PHP 5.2.3

PHP 5.2.8
PHP 5.2.9
PHP 5.2.9-1
PHP 5.2.9-2
PHP 5.2.10
PHP 5.2.11

PHP 5.3.0
PHP 5.3.1

All working OK

[Gerlof]

OS on test PC Windows XP, browser Google Chrome

FreeBSD - PHP 5.2.6 >> I can see Chinese/Japanese, Greek and Russian
characters so: OK
Linux - PHP 5.2.5 >> Expected = actual, but I cannot see the foreign
characters I mentioned above, so: not OK?

On 5 Jan, 15:42, Hannes Papenberg <hackwa...@googlemail.com> wrote:

>  ini_test.zip
> 1KViewDownload

[Phoca]

Hi,

OpenSuse11.1 - PHP5.2.6 - Apache - Ok
WinXP - PHP5.2.8 - Apache - OK

[webamoeba]

Windows XP Pro 32 bit

Using WampServer

PHP 5.2.0 = OK
PHP 5.2.6 = OK

[Amy Stephen]

Windows Vista Ultimate Edition Service Pack 2
XAMPP - Apache/2.2.12
PHP/5.3.0

Works great - thanks Hannes.

[Garstud]

Apache 2.2.11 - WAMP 2.0 / Windows Vista SP2
PHP 5.2.0
PHP 5.2.3

PHP 5.2.8
PHP 5.2.11

PHP 5.3.0
PHP 5.3.1

All Expected and Actual strings are OK

P.S. : for multiple PHP version tests,
i have added the bellow code in your script to be sure of the version
i was testing :

<?php echo "<br>I am using PHP v".PHP_VERSION; ?>

[Andrew Eddie]

2010/1/6 Hannes Papenberg <hack...@googlemail.com>:

> and the function calls in Joomla itself could look like this:
> echo JText::_('core.string1');

I'd prefer to go with
echo JText::_('j.Invalid_Request');

just to save a few characters :)

Anyway, the main thing here is that quoted sections in the value are
concatenated. To represent and anchor tag, you'd do something like
this (I changed the constant to _Q_):

A_TAG="<a href="_Q_"http://joomla.org"_Q_">Joomla!</a>"

That translates to a string being made of of

<a href= + _Q_ + http://joomla.org + _Q_ + >Joomla!</a>

That's not the end of the world but we'll need to be careful.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

[Aytuğ AKAR]

Windows NT 5.2
Microsoft-IIS/6.0
php 5.2.9

OK (with Turkish special chars too)

======

CentOS 5+
Apache 2.2.11
php 5.2.11

OK (with Turkish special chars too)

======

>  ini_test.zip
> 1KViewDownload

[Andrew Eddie]

2010/1/6 Hannes Papenberg <hack...@googlemail.com>:

>
> If all tests return a positive result, the translation files in 1.6
> would look something like this:
> [CORE]
> STRING1="Some translated String"
>
> [COM_MEDIA]
> PICTURE="Some picture string"

Just thinking about it some more. I don't think it's particularly
useful to have the sections in the ini file. It's a cool idea but I
think it will get unmanageable in the end. Plus it's a little extra
processing to account for it.

I think we should stick with no sections and fully namespace the keys.

[infograf768]

+ 1, Andrew.
I see quite a few reasons why we should keep the full keys.
1. Easier on Translators
2. Easier when searching keys
3. Easier when debugging
4. Easier on key refactoring (all breaks if the period is forgotten)

@Hannes
Keeping the full keys should not change too much code for this great
improvement you are bringing here and which makes us all very excited
too.

On 6 jan, 09:23, Andrew Eddie <mambob...@gmail.com> wrote:
> 2010/1/6 Hannes Papenberg <hackwa...@googlemail.com>:

>
>
>
> > If all tests return a positive result, the translation files in 1.6
> > would look something like this:
> > [CORE]
> > STRING1="Some translated String"
>
> > [COM_MEDIA]
> > PICTURE="Some picture string"
>
> Just thinking about it some more.  I don't think it's particularly
> useful to have the sections in the ini file.  It's a cool idea but I
> think it will get unmanageable in the end.  Plus it's a little extra
> processing to account for it.
>
> I think we should stick with no sections and fully namespace the keys.
>
> Regards,

> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer

[Hannes Papenberg]

At the moment it supports both, with and without sections. As you wrote
to me, the overrides might still be missing, otherwise the whole thing
is working in the trunk, except that some language keys and some INI
files have not been refactored yet.

Hannes

[Mark Dexter]

+1 on not using sections.

At first I thought sections were a cool idea and would shorten the tags in the files. However, we use search/replace a lot to find where these strings are used. So having the tag in the ini file always match the tag in the code is very, very handy. Tracking down language strings would be much harder if they don't always match.

Mark

--
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To post to this group, send an email to joomla-dev...@googlegroups.com.

To unsubscribe from this group, send email to joomla-dev-frame...@googlegroups.com.

[Amy Stephen]

Is it possible to have a "common terms" namespace?

There are many words/phrases that are repeated - so - namespacing to a
specific extension also means increasing the strings - more work for
translators and likely has so impact on performance.

On 6 Jan, 08:16, Mark Dexter <dextercow...@gmail.com> wrote:
> +1 on not using sections.
>
> At first I thought sections were a cool idea and would shorten the tags in
> the files. However, we use search/replace a lot to find where these strings
> are used. So having the tag in the ini file always match the tag in the code
> is very, very handy. Tracking down language strings would be much harder if
> they don't always match.
>
> Mark
>
> On Wed, Jan 6, 2010 at 3:23 AM, Hannes Papenberg

> <hackwa...@googlemail.com>wrote:

> > >> Andrew Eddiehttp://www.theartofjoomla.com-the art of becoming a Joomla

> > developer
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Joomla! Framework Development" group.
> > To post to this group, send an email to
> > joomla-dev...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > joomla-dev-frame...@googlegroups.com<joomla-dev-framework%2Bunsu...@googlegroups.com>

[Mark Dexter]

One thing that is very easy to miss for us native English speakers is the following: words or phrases can have the same meaning in one language in different contexts, whereas in another language the word or phrase needs to change. For example (I am making this up), in English we could use the word "name" to mean the name of a person, a category, or many other things. In another language, there might be different words for name of a person, name of an article, and so on.

So, there is a risk in trying to re-use the same language tag in different places, since it reduces the flexibility for translators to put the correct word in for each context.

Someone from the TT correct me if I'm wrong, but I think in general it is preferable to err on the side of duplicating tags rather than to assume that the same tag can be re-used in a different context.

No big deal, but just something to keep in mind. Mark

To unsubscribe from this group, send email to joomla-dev-frame...@googlegroups.com.

[Ed Stafford]

That's certainly possible based on area vernacular. If we're talking
car-parts, en_US is "hood" where en_GB is "bonnet". Restroom vs. Loo,
Mom vs. Mum.. Babe vs. Bub. There's enough difference in the
terminology (es_ES vs es_MX is another good example of deviations of
the same language) that you'd want to be careful about interchanging.

On Wed, Jan 6, 2010 at 10:49 AM, Mark Dexter <dexter...@gmail.com> wrote:
> One thing that is very easy to miss for us native English speakers is the
> following: words or phrases can have the same meaning in one language in
> different contexts, whereas in another language the word or phrase needs to
> change. For example (I am making this up), in English we could use the word
> "name" to mean the name of a person, a category, or many other things. In
> another language, there might be different words for name of a person, name
> of an article, and so on.
>
> So, there is a risk in trying to re-use the same language tag in different
> places, since it reduces the flexibility for translators to put the correct
> word in for each context.
>
> Someone from the TT correct me if I'm wrong, but I think in general it is
> preferable to err on the side of duplicating tags rather than to assume that
> the same tag can be re-used in a different context.

--
Ed Stafford

[infograf768]

You are right on spot, Mark.
Some of our languages do indeed need changing values (even apparently
simple ones in English) depending on context.
Better duplicate indeed, specially taking into account this great
improvement in speed.

On 6 Jan, 17:49, Mark Dexter <dextercow...@gmail.com> wrote:
> One thing that is very easy to miss for us native English speakers is the
> following: words or phrases can have the same meaning in one language in
> different contexts, whereas in another language the word or phrase needs to
> change. For example (I am making this up), in English we could use the word
> "name" to mean the name of a person, a category, or many other things. In
> another language, there might be different words for name of a person, name
> of an article, and so on.
>
> So, there is a risk in trying to re-use the same language tag in different
> places, since it reduces the flexibility for translators to put the correct
> word in for each context.
>
> Someone from the TT correct me if I'm wrong, but I think in general it is
> preferable to err on the side of duplicating tags rather than to assume that
> the same tag can be re-used in a different context.
>
> No big deal, but just something to keep in mind. Mark
>

> > > > >> Andrew Eddiehttp://www.theartofjoomla.com-theart of becoming a

> > Joomla
> > > > developer
>
> > > > --
> > > > You received this message because you are subscribed to the Google
> > Groups
> > > > "Joomla! Framework Development" group.
> > > > To post to this group, send an email to
> > > > joomla-dev...@googlegroups.com.
> > > > To unsubscribe from this group, send email to
> > > > joomla-dev-frame...@googlegroups.com<joomla-dev-framework%2Bunsu...@googlegroups.com>

> > <joomla-dev-framework%2Bunsu...@googlegroups.com<joomla-dev-framework%252Buns...@googlegroups.com>

[Hannes Papenberg]

I wrote the code in a way, that you can have sections if you want, but
don't have to have them. Currently there are no sections in the
translation files in the jtext branch and it still works. The only
limitation is, that you can't have . (periods) in the keys. So if you
write an extension where you want to use sections, just use them.
Otherwise it works the same as before.

Hannes

P.S.: My gut feeling just likes sections. :-)

> <mailto:mambob...@gmail.com>> wrote:
> >
> >> 2010/1/6 Hannes Papenberg <hackwa...@googlemail.com

> <mailto:hackwa...@googlemail.com>>:

> >>
> >>
> >>
> >>
> >>> If all tests return a positive result, the translation files
> in 1.6
> >>> would look something like this:
> >>> [CORE]
> >>> STRING1="Some translated String"
> >>>
> >>
> >>> [COM_MEDIA]
> >>> PICTURE="Some picture string"
> >>>
> >> Just thinking about it some more. I don't think it's particularly
> >> useful to have the sections in the ini file. It's a cool idea
> but I
> >> think it will get unmanageable in the end. Plus it's a little
> extra
> >> processing to account for it.
> >>
> >> I think we should stick with no sections and fully namespace
> the keys.
> >>
> >> Regards,
> >> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming
> a Joomla developer
> >>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! Framework Development" group.
> To post to this group, send an email to
> joomla-dev...@googlegroups.com

> <mailto:joomla-dev...@googlegroups.com>.

> To unsubscribe from this group, send email to
> joomla-dev-frame...@googlegroups.com

> <mailto:joomla-dev-framework%2Bunsu...@googlegroups.com>.

[Christophe Demko]

It's a good idea for developers to have the possibility to use
sections.

Example, for a very big component with a lot of views (see admin/
com_users).

The developer can separate its strings into several parts:
[GROUP]

USERS_GROUP_DELETE_FAILED=An error was encountered while removing a
group: %s.
...

[GROUPS]

Put strings relative to the "groups" view

But we have to keep the keys as significant as possible, i.e. sections
are equivalent to comments but can be used by the com_localise
component (which have to be finished). Note that the dev have to use
the long version of the key (USERS_ prefix)

> >> Andrew Eddiehttp://www.theartofjoomla.com-the art of becoming a Joomla developer

[Amy Stephen]

On Jan 6, 11:12 am, infograf768 <infograf...@gmail.com> wrote:
> You are right on spot, Mark.
> Some of our languages do indeed need changing values (even apparently
> simple ones in English) depending on context.
> Better duplicate indeed, specially taking into account this great
> improvement in speed.

Certainly, although there are valid situations where a word or phrase
is intended to be consistently used within Joomla! (ex. Component,
Module, Template, Category, Article, etc.).

Question - Will developers still be able to 'override' the ini file
for an Extension using the $language->load method? If so, we still
have flexibility needed.

Thanks.

[Andrew Eddie]

2010/1/7 Amy Stephen <amyst...@gmail.com>:

> Is it possible to have a "common terms" namespace?

Yes. Look in the admin en-GB.ini for all the JSomething strings.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

[Andrew Eddie]

2010/1/7 Amy Stephen <amyst...@gmail.com>:

>
> Question - Will developers still be able to 'override' the ini file
> for an Extension using the $language->load method? If so, we still
> have flexibility needed.

Any extension can do that (generally at it's peril). Strings will get
processed in the order of loading and execution of JText. Consider
this:

Load core ini's
echo JText::_('JYes') -> Yes
Load extension with override of JYes
echo JText::_('JYes') -> Too right mate!

You will have at least two different instances of that on the same page.

There is, however, a master override file but that would be used by
the site master and takes precedence regardless of what an extension
loads.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

[ErikThe3rd]

Are the strings of J1.5 in en-GB.ini contained in J1.6 ? Or asked
other around. Can a developer assume, that the strings in en-GB.ini
(with all the translated childs: es-CA.ini, fr-FR.ini) from J1.5 also
be used in J1.6 ?

Erik

[Hannes Papenberg]

No, since we have to make the keys proper INI-keys, which means that
they will all change.

Hannes

[Ian MacLennan]

Which actually raises a point I had not thought of.  Although it would be nice to have some strings that are reusable and common, having third party developers rely on our strings means we can't change them.  I would thus argue that we should recommend third party developers not use our strings to give the core more flexibility.

Ian

--
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To post to this group, send an email to joomla-dev...@googlegroups.com.

To unsubscribe from this group, send email to joomla-dev-frame...@googlegroups.com.

[Hannes Papenberg]

I don't think its really usefull to tell developers to not use our
strings. If you extend this consequently, you would have to say that
developers shouldn't use our tables, classes and functions, since they
have changed from 1.5 to 1.6, too. We can only guarantee developers that
we wont change functions, classes and strings between maintenance
releases, everything else is just plainly a lie from our side.

Anyway, I started to write a little bit of documentation about the new
translation strings, which I'd like you to review and comment and please
correct the language where apropriate. :-) Otherwise please take a look
at the jtext branch and tell me if you see anything that is broken in
terms of my coding, so that I can commit it to trunk as soon as
possible. Please don't report missing translations, since quite a lot of
the translation files are still broken, since the keys are not written
by these new standards and thus the parsing of the files breaks. We will
have to change these keys all throughout Joomla to fix this.

But now on to the documentation:
===================================
Joomla! Translation Files
This document is valid for Joomla! 1.6 and following
This document describes how to translate fixed strings in the code of
Joomla and its extensions. Starting with Joomla 1.6, a (strict) new
naming scheme and a new file format for the translation files has been
established. This new naming convention and file format ensures, that we
get the maximum performance out of the system and that translations work
the best in all languages.

Naming Convention

Translation Keys
Translating a hard-coded string in your code requires a unique key,
which gets replaced by the Joomla translation engine to its translated
counterpart. These keys should be uppercase and consist only of the
characters A-Z, 0-9 and _ (underscore). Please keep in mind that a word
might have more than one meaning in your language, which is translated
into seperate words in another language. To prevent collisions in the
translations, you should namespace your translation keys by one of the
following two methods:
1. Prefix each key with your extensions name
Each key gets a prefix with a three letter code for the type of
extension, followed by an underscore and the (abbreviated) name of the
extension, followed again by an underscore and the actual translation
key. Example: MOD_CUSTOM_HELLO_TEST
2. Use sections in the translation files
In the translation file, add a section tag before the keys to be
namespaced. All keys following this section tag will be added to that
namespace. A section tag is opened by a [-bracket, followed by a
three-letter extensions identifier, an underscore and the (abbreviated)
name of the extension and then closed by a ]-bracket. This tag is on its
own line. There is no tag to close the namespace in the file. A new
section tag automatically closes the previous namespace and opens a new
one. Example: [MOD_CUSTOM]
The actual complete translation key consists of the namespace, followed
by a . (period) and the actual translation key. Example:
MOD_CUSTOM.HELLO_TEST
The following three-letter-codes are valid:
COM - Components
MOD - Modules
PLG - Plugins
TPL - Templates
LIB - Libraries
J - General core strings
A general rule of thumb for the keys: The string following the extension
prefix should be short and descriptive. For short names/strings, just
copy them according to the naming rule, converting the string to
uppercase and A-Z, 0-9 and _ characters. For descriptions use a short
string and add _DESC to it. For a longer string that is not necessarily
a description, find an abbreviated version of the string.

File Format
Joomla uses the INI-fileformat for its translation files. These files
need to be saved as UTF-8 and NO-BOM.
Comments in these files are started with a ; (semicolon) and are ended
with a new line.
Each line in the file can contain one key-value-pair for the
translation, with the key in the format described above, followed by a =
(equal-sign) and the translation wrapped in " (quotes). Quotes in the
translated string need to be replaced with "QUOTE" (a double quote,
followed by QUOTE in uppercase and again followed by a double quote).
Each file needs to begin with a comment describing the source of the
file and its copyright.

Example for a translation file
===============================
; $Id: en-GB.ini 14068 2010-01-07 05:19:09Z hackwar $
; Joomla! Project
; Copyright (C) 2005 - 2009 Open Source Matters. All rights reserved.
; License GNU General Public License version 2 or later; see
LICENSE.txt, see LICENSE.php
; Note : All ini files need to be saved as UTF-8

MOD_CUSTOM_HELLO_TEST="Hello test"
MOD_CUSTOM_HELLO_DESC="This is a test description, which can contain
<b>HTML</b>"

[MOD_CUSTOM]
GOODBYE_DESC="We also want to show how you can use
<justify>sections</justify>"
LINK_DESC="<a href="QUOTE"joomla.org"QUOTE">Link to Joomla</a>"

Example how to use these translations in a code
echo JText::_('MOD_CUSTOM_HELLO_TEST'); //Returns 'Hello test'
echo JText::_('MOD_CUSTOM.LINK_DESC'); //Returns '<a
href="joomla.org">Link to Joomla</a>'

Am 07.01.2010 15:23, schrieb Ian MacLennan:
> Which actually raises a point I had not thought of. Although it would
> be nice to have some strings that are reusable and common, having
> third party developers rely on our strings means we can't change
> them. I would thus argue that we should recommend third party
> developers not use our strings to give the core more flexibility.
>
> Ian
>
> On Thu, Jan 7, 2010 at 8:16 AM, Hannes Papenberg
> <hack...@googlemail.com <mailto:hack...@googlemail.com>> wrote:
>
> No, since we have to make the keys proper INI-keys, which means that
> they will all change.
>
> Hannes
>
> Am 07.01.2010 12:40, schrieb ErikThe3rd:
> > Are the strings of J1.5 in en-GB.ini contained in J1.6 ? Or asked
> > other around. Can a developer assume, that the strings in en-GB.ini
> > (with all the translated childs: es-CA.ini, fr-FR.ini) from
> J1.5 also
> > be used in J1.6 ?
> >
> > Erik
> >
> > Andrew Eddie wrote:
> >
> >> 2010/1/7 Amy Stephen <amyst...@gmail.com

> <mailto:amyst...@gmail.com>>:

> >>
> >>> Is it possible to have a "common terms" namespace?
> >>>
> >> Yes. Look in the admin en-GB.ini for all the JSomething strings.
> >>
> >> Regards,
> >> Andrew Eddie
> >> http://www.theartofjoomla.com - the art of becoming a Joomla
> developer
> >>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! Framework Development" group.
> To post to this group, send an email to
> joomla-dev...@googlegroups.com

> <mailto:joomla-dev...@googlegroups.com>.

> To unsubscribe from this group, send email to
> joomla-dev-frame...@googlegroups.com

> <mailto:joomla-dev-framework%2Bunsu...@googlegroups.com>.

[ErikThe3rd]

I would like to add:

> For descriptions use a short string and add _DESC to it.

For tooltips add _TOOLTIP (or just _TIP).

Erik

[Andrew Eddie]

2010/1/8 Hannes Papenberg <hack...@googlemail.com>:

> I don't think its really usefull to tell developers to not use our
> strings.

No, but I'd qualify that by saying that you can use ours providing the
intended meaning is the same. If you as a 3PD don't want to risk that
changing from time to time, then use your own version.

> 1. Prefix each key with your extensions name
> Each key gets a prefix with a three letter code for the type of
> extension, followed by an underscore and the (abbreviated) name of the
> extension, followed again by an underscore and the actual translation
> key. Example: MOD_CUSTOM_HELLO_TEST

I prefer the prefix but I would just stipulate that the prefix needs
to ensure uniqueness on the rendered page. I think COM_ should
definitely be optional and MOD_, TPL_, etc should be encouraged but
also optional (for example, 3PD's like RocketTheme might use RT_ and
I've certainly used JX_ or TAOJ_ for my stuff).

I'm still sceptical as to whether we need to add additional computing
complexity for sections.

> Quotes in the
> translated string need to be replaced with "QUOTE" (a double quote,
> followed by QUOTE in uppercase and again followed by a double quote).

I'd prefer something with less risk of collision (and less characters,
hehe). _Q_ or _QQ (double-quote, get it?) would be my suggestion.
Note that if the true-quote need to be at the end of the string, you
don't follow it with another quote, eg:

STRING=_Q_"this is quoted"_Q_

[ErikThe3rd]

Hannes, specify also the character space for sections.
see PHP bug report at: http://bugs.php.net/bug.php?id=49461

Erik

[Christophe Demko]

Do we use this functionnality of parse_ini_file: ?

KEY[]=value1
KEY[]=value2

(for days of week, language list, ... )

> > >     >> 2010/1/7 Amy Stephen <amystep...@gmail.com
> > >     <mailto:amystep...@gmail.com>>:

>
> > >     >>> Is it possible to have a "common terms" namespace?
>
> > >     >> Yes.  Look in the admin en-GB.ini for all the JSomething strings.
>
> > >     >> Regards,
> > >     >> Andrew Eddie

> > >     >>http://www.theartofjoomla.com- the art of becoming a Joomla

[Ian MacLennan]

This looks fine to me.  Though I think we will also need to publish a coles notes versions so that people can see in 6 lines what the format is.

I wasn't clear that we had reached an agreement on using sections and there seems to be push back from the TTs on this based on some valid points (searchability and maintainability of language files).

Should we consider going without sections?

Ian

[Hannes Papenberg]

Yes, some people dislike the sections, which is why I wouldn't use them
in the core. I would still leave in the possibility to use them for
third party devs. The code in the jtext branch supports both and there
is no noticeable speed difference in enabling the parsing of sections or
not. And we didn't actually come to an agreement on this... Call this a
rogue action by me... I hope its okay with you guys. Otherwise we can
take a step back and invite a bigger audience to a chat in IRC again to
discuss this.

Hannes

> <http://joomla.org>"QUOTE">Link to Joomla</a>"

>
> Example how to use these translations in a code
> echo JText::_('MOD_CUSTOM_HELLO_TEST'); //Returns 'Hello test'
> echo JText::_('MOD_CUSTOM.LINK_DESC'); //Returns '<a

> href="joomla.org <http://joomla.org>">Link to Joomla</a>'

>
> Am 07.01.2010 15:23, schrieb Ian MacLennan:
> > Which actually raises a point I had not thought of. Although it
> would
> > be nice to have some strings that are reusable and common, having
> > third party developers rely on our strings means we can't change
> > them. I would thus argue that we should recommend third party
> > developers not use our strings to give the core more flexibility.
> >
> > Ian
> >
> > On Thu, Jan 7, 2010 at 8:16 AM, Hannes Papenberg
> > <hack...@googlemail.com <mailto:hack...@googlemail.com>

> <mailto:hack...@googlemail.com

> <mailto:hack...@googlemail.com>>> wrote:
> >
> > No, since we have to make the keys proper INI-keys, which
> means that
> > they will all change.
> >
> > Hannes
> >
> > Am 07.01.2010 12:40, schrieb ErikThe3rd:
> > > Are the strings of J1.5 in en-GB.ini contained in J1.6 ?
> Or asked
> > > other around. Can a developer assume, that the strings in
> en-GB.ini
> > > (with all the translated childs: es-CA.ini, fr-FR.ini) from
> > J1.5 also
> > > be used in J1.6 ?
> > >
> > > Erik
> > >
> > > Andrew Eddie wrote:
> > >
> > >> 2010/1/7 Amy Stephen <amyst...@gmail.com
> <mailto:amyst...@gmail.com>

> > <mailto:amyst...@gmail.com <mailto:amyst...@gmail.com>>>:

> > >>
> > >>> Is it possible to have a "common terms" namespace?
> > >>>
> > >> Yes. Look in the admin en-GB.ini for all the JSomething
> strings.
> > >>
> > >> Regards,
> > >> Andrew Eddie
> > >> http://www.theartofjoomla.com - the art of becoming a Joomla
> > developer
> > >>
> >
> >
> > --
> > You received this message because you are subscribed to the
> Google
> > Groups "Joomla! Framework Development" group.
> > To post to this group, send an email to
> > joomla-dev...@googlegroups.com
> <mailto:joomla-dev...@googlegroups.com>

> > <mailto:joomla-dev...@googlegroups.com

> <mailto:joomla-dev...@googlegroups.com>>.
> > To unsubscribe from this group, send email to
> > joomla-dev-frame...@googlegroups.com
> <mailto:joomla-dev-framework%2Bunsu...@googlegroups.com>

> > <mailto:joomla-dev-framework%2Bunsu...@googlegroups.com
> <mailto:joomla-dev-framework%252Buns...@googlegroups.com>>.

[ErikThe3rd]

Hannes examples suggest COM_* and MOD_* and PLG_* sections, but
currently each component / module / plugin has its own .ini file in
addition to frontend and backend versions. So I do not see the
benefit of sections within a single .ini file.

Erik

[Hannes Papenberg]

We are not talking about sections, but prefixing the keys to create
namespaces. And the problem is not solved by putting the strings in
different INI files, since several of those files are loaded during a
pageload. It basically makes no difference if we have these strings in
10 different files or all in just one. I'd say, on a typical site, you
would load about 20 of those translation files. 10 different plugins,
about 7 modules, a component, a template and a general language file.
All these strings are in the same namespace, so if you have a JYES in
our general language file and a JYES in your module translation file,
the later overwrites the former string.

Now, sections would make sense in the override file or if you are
talking about a large extension with a component and several plugins and
modules where you want to have all strings in just one file to ease the
work for translators for the whole component.

Hannes

[infograf768]

Tested Jtext branch. Sections removed, override and use of "_QQ_"
works great.

Remains an issue:
The single quotes and double quotes are not properly displayed when
the values are used in the tooltips.
Example:

CONTENT_CREATED_BY_DESC="Created's by "_QQ_"the best formater
around"_QQ_

is displayed as

Created\'s  by \

Only way to overpass this is to use &apos; and &quot;
This defeats the whole purpose of the DEFINE imho.

Any solution?

[Ian MacLennan]

Is that an issue for tooltips apart from the use of JText?  As I told you JM, I think that is a tooltips issue and is off topic for the current discussion.

Ian

[JM Simonet]

You are right.

-- 

Merci de ne pas renvoyer de pièces attachées automatiquement.

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

Jean-Marie Simonet/infograf

info...@orange.fr

http://www.info-graf.fr