Thanks for coding this, Peter!

For anyone interested, here's the tracker item on JoomlaCode:
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=30370

The only minor issue with using this approach instead of JText::sprintf() is that this approach enforces a particular left-to-right order. With sprintf(), the replacement codes can be moved as necessary for right-to-left languages.

@jmcameron Thanks, never thought of that. But how can you tell JText::sprintf to order them the other way round? This doesn't seem to be built in behavior for any of the JText methods.
Or do you mean you can do that via an if structure in your own code?

http://docs.joomla.org/Formatted_fields_in_language_translation_strings

Yeah, but that is no different than using the method I built into the JText::_().

You can do:

<field ... label="STRING,ONE,TWO,THREE" />

With:

STRING="Counting down: %3$s, %2$s, %1$s"
ONE="1"
TWO="2"
THREE="3"

Result:
Counting down: 3, 2, 1

@nonumber To explain further, here a made-up example. Suppose you want to print a warning that an ID is wrong:

JText::sprintf('WRONG_ID', id);

The translation item in the .ini file might look like this in a LTR language (like English):

WRONG_ID="Wrong ID: %d"

But in a RTL language, it could be changed in the translation .ini file:

WRONG_ID="%d :ID Bad"

Where "ID Bad" would be in some other RTL languge.

Notice that the original JText::sprintf call would not change, but the message could be handled in a RTL or LTR manner by changing the position of the %d replacement item in the translation files.

However, if you use the new JText::_() approach, you cannot change the location of the ID in the output.

Sorry, I just reread the original proposal above and maybe it will be able to handle the RTL issues. It looks like the plan is to extend JText::_() to work identically to JText::sprintf() if it has extra arguments. If that is the case, then you can ignore my comments.

Yes, I'll ignore your replies :)

But please test the patch, so we can get this into core (hopefully into
3.1)...

Interesting suggestion Peter.

Do you have more in use examples? The XML example does give a good idea of the concept of the dynamic added though. But it also raises an eyebrow whether this could get close to behave as concatenating strings and bring on difficualty to those helping localising the strings.

Mixing strings and making them more dynamic, may be a fine extra option for the source language, but I have some concern it may end up becoming more difficult to localise the dynamic source if used for mixing more complex strings, and give some issues with languages using different terms/words/forms when in different context.

I don't see how that discussion is any more relevant to this than the ability to use JText::_sprintf() in an extensions PHP code.

PS: This also works and is pretty cool:

<field name="myoption" type="list" default="2" label="Options">
    <option value="1">MY_OPTION,1</option>
    <option value="2">MY_OPTION,2</option>
    <option value="3">MY_OPTION,3</option>
    <option value="4">MY_OPTION,4</option>
    <option value="5">MY_OPTION,5</option>
</field>

So you can have dynamic option names, without needing loads of separate language sting where only the number (or type) differs.
All your language file needs is:

MY_OPTION="My option: %s"

Just thought of another use:

You can push multiple strings and concatenate them (or whatever you want) by using:
description="%s %s %s,MY_STRING_ONE,MY_STRING_TWO,MY_STRING_THREE"
Or even:
description="<h2>%s</h2> %s <em>%s</em>,MY_STRING_ONE,MY_STRING_TWO,MY_STRING_THREE"

I committed a change to make this possible.

Added examples to description...

+1 for the last changes ;) I hate to have translations like the last example inside the language files.

Thanks, but please test it instead of +1-ing it.

OK just so I can cover the bases here as a certified idiot. I can definately see the usefulness BUT all your examples use the XML file. Would it not be easier to use JText::sprintf() on the XML file rather than JText? I would have thought that would involve less code as well!

No, that would involve a lot more code, as you would need to add pretty much the same checks/code I added to one file now, to all possible field type files.

Also, adding the sprintf ability to the main JText method opens up more possibilities than just for xml files. You can use this in any field/value that is passed through the JText method.

Hi Johnny,

Please test the implementation of the patch, as it cannot be added without good testing.

Cheers

@johnnydement The discussion about whether or not you think it is a good idea to use the sprintf functionality is useless here.
That is already possible inside php code. All that this PR does is extend that possibility to the XML files and other areas were you cannot directly call onto te sprintf metod.
So this (the splitting of strings into chunks) is noting new to Joomla.

Like Nick says: please test this PR to get it committed.

@nonumber - can you find me on Skype ('cheesegrits', Hugh Messenger, Huntsville, AL)? I'm trying to test this for you, having problems getting the patch applied. I really like this idea, and have immediate uses I could put it to with Fabrik (the extension I co-author).

Tested. Works. Posted test result on tracker.

Definite +1 for getting this adopted.

Also made a quick test on this and I already have a few places where I really could use this feature -- starting from manifest description as I want to display current version number in it without changing the translation.

@mahagr Thanks. Indeed, great example :)
Can you please test if it works ok and report back with a 'successful test' on the tracker?
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=30370

I really hate using tracker... Done.

Don't we all...

On Thu, May 9, 2013 at 11:10 AM, Matias Griese notifications@github.comwrote:

I really hate using tracker... Done.

—
Reply to this email directly or view it on GitHub#880 (comment)
.

+1 on the hating of the tracker :P

... yes we do ;)

Well, maybe in a masochistic kind of way .... no, not even then.

On Thu, May 9, 2013 at 11:55 AM, Nikolai Plath notifications@github.comwrote:

... yes we do ;)

—
Reply to this email directly or view it on GitHub#880 (comment)
.

So does this have enough tests now to go forward?

Hi, can pls you add PR description to docs.joomla.org? I think most developers still use it as a reference

Hello, Just discover a major backward incompatiblity
If the text given to the JText::_ function is not a DEFINE but a classical text. This will returns a partial part of the text

Example: echo JText::_("THIS IS A TEXT,THIS PART WILL NOT BE RETURNED')
result: THIS IS A TEXT

So the test that is just checking if first part of the text contains only uppercase is not enough. You should check that: $firstpart != JText::_($firstpart) to be sure it's a language define)

You are not supposed to put stuff in the JText::_() if it is not a language string.
language strings are uppercase and have no spaces or comma's.
'THIS IS A TEXT,THIS PART WILL NOT BE RETURNED' is NOT a valid language string.

If your extension is doing that, then it is doing it wrong. Use language strings and ini files.

I think my example was not clearly understood
MY SUPER TEXT, WITH A COMMA is not a key in my example, is a simple text.(already in the correct language)
I don't want MY SUPER TEXT, WITH A COMMA to be replaced by another text
I want JText to return it without any modification as this text is not a key.

So maybe your next question is why are you given this sentence to JText if this is not a text to translate ? Need of JText is unecessary at all.

It's just because in the code I don't know if the value to pass to JText::_() will be a KEY or a Text because this is a user entry.
Let's take an example. You have a "object with a name" in your component.
Some users of your component are using only 1 language to then will put the final string in the field.
But now another user is using several languages and just one 1 object to be translated automatically depending on visitor's language. Then they enter a KEY in the field and then add the KEY translation in the language files.
So in the code a call to JText in done all cases. if the value is a KEY it's translated, if it's a text the text is simply returns.

This is no more possible with this code.

I don't see anything in the API docs that says you are ONLY supposed to use language INI keys. It might be implied in the examples, and is how most folk use it, but I don't see any specific restriction in the docs. I have several uses of JText::() where I'm not using FOOBAR style INI keys, but rather leveraging JText to allow admins to provide for translation of arbitrary, user supplied strings.

-- hugh

"You are not supposed to put stuff in the JText::_() if it is not a language string.
language strings are uppercase and have no spaces or comma's."

===> Just wondering why in this case, there is the following code in the new JText implementation
" if (strtoupper($test) === $test) "

This is not needed, if it's always language strings constants ?