• Language keys normalisation

[infograf768]

Andrew proposed and started to implement new language keys in 1.6.
Basically they should not collide.

I propose we normalise this.

Components:
NAMEOFCOMPONENT_WHATEVER

Modules:
MOD_NAMEOFMODULE_WHATEVER

Plugins:
PLG_NAMEOFPLUGIN_WHATEVER

which would give for example
PLG_TINY_FUNCTIONNALITY
PLG_TINY_DESCFUNCTIONNALITY
etc.

What do you think?

[jonnsl]

I think that should be more especific like:

NAMEOFCOMPONENT_JSUCCES_WHATEVER
-> For succes messages.

NAMEOFCOMPONENT_JERROR_WHATEVER
-> For error messages.

NAMEOFCOMPONENT_JOPTION_WHATEVER
-> For a option in a list.

NAMEOFCOMPONENT_JFIELD_WHATEVER_LABEL
-> For the label of a field.

NAMEOFCOMPONENT_JFIELD_WHATEVER_DESC
-> For the description of the field.

NAMEOFCOMPONENT_JTOOLBAR_WHATEVER
-> For a custom toolbar button.

NAMEOFCOMPONENT_HEADING_WHATEVER
-> For the heading of a table

NAMEOFCOMPONENT_JSTATE_WHATEVER
-> For a custom state

NAMEOFCOMPONENT_JFILTER_WHATEVER
-> For a custom filter

it takes very work to do, but will be much easier translate.

There are 2,828 strings in JTEXT, If we have the help of 30 people,
will be less than 100 words for each. : )

[Phoca]

Hi Jean-Marie,
I think it is OK. I don't know if in 1.6 there will be some similar
function like the following (I will explain it in example) but there
should be something like this.

Example:
I pasted this type of strings into Phoca Gallery component and now
(after running this on production sites) I am getting the following
problem. Let's say we have:

PHOCAGALLERY_SOME_LONG_STRING=Some Long String

It is OK when the language file is complete but sometimes happens,
that the language pack is not complete (and the developer cannot do
anything as he/she is dependent ot the translation of some external
translator) and users get the following string in the component

PHOCAGALLERY_SOME_LONG_STRING

Such long strings can destroy the whole design of the site.
Mostly the English (basic) languge pack is complete but it doesn't
help to users because they use own language pack, which is mostly not
complete. So there is an English translation but it will be not used
because the not complete translation of user's language is used. And
if this not complete translations is used and something is not
translated, then user get such strings (in frontend, in backend):

PHOCAGALLERY_SOME_LONG_STRING ... which is not good :-( (because of the design)

So maybe two possible solutions can be done:

1) If the string is not translated by user's language (because his/her
translation pack is uncomplete) then take the translation from basic
language (English) so it looks like:
Some Long String and not PHOCAGALLERY_SOME_LONG_STRING. It means:

PHOCAGALLERY_SOME_LONG_STRING ==> not found in the user's language
pack ==> Check the basic language pack (English) and paste the basic
string into the component

or

2) check the name of the component (module, plugin) and cut the name
of the component(module, plugin) in case the string will be not
translated. It means:

PHOCAGALLERY_SOME_LONG_STRING ==> not found in the user's language
pack ==> remove the name of the component so you get ==>
SOME_LONG_STRING ==> remove underscore and e.g. change the upper,lower
case of the characters e.g. ==> Some Long String

Or some other mechanism which will prevent from DISPLAYING the string
in this form:
PHOCAGALLERY_SOME_LONG_STRING

I know the best way is translate all strings, but this is not possible
in large projects as most of the translation packs are not complete
:-( But e.g. if user get 90% of translation of e.g. backend strings in
some component it is still helpful but what is not helpful is that the
rest of the strings (10%) will destroy the design e.g. of the site (as
such long strings will do :-( )

Only an idea, maybe this is solved by some better mechanism, if yes
please let me know.

Thank you, Jan

2009/12/30 infograf768 <infog...@gmail.com>:

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

[Andrea Tarr at Tarr Consulting]

And the template strings?

TPL_NAMEOFTEMPLATE_WHATEVER

Andy

Andrea Tarr
www.tarrconsulting.com

Components:
NAMEOFCOMPONENT_WHATEVER

Modules:
MOD_NAMEOFMODULE_WHATEVER

Plugins:
PLG_NAMEOFPLUGIN_WHATEVER

What do you think?

--

[JM Simonet]

Hello Jan.

I do understand where you come from. It takes time to control the validity of all the Translation provided for a said extension.

In fact, what would break display in this case is a long key for a short value, i.e.

PHOCAGALLERY_SOME_VERY_VERY_LONG_KEY= Short_value

What you ask is that Joomla! takes care of mistakes or lack of updating done by Translators.

I do not see that as core functionnnality.

Let's look at the various proposals you make:

1. Replace the absent value by the English one.

This would not always work as quite a few users are deleting the English language folders.

2. Take off prefix suggested above, name of extension, change the Key to lower case and take off underscores to display that result

That could still break display and would not be of help to correct the issue.

Example

PLG_PHOCAGALLERY_SOME_VERY_VERY_LONG_KEY=Short_value

would give

"Some very very long key"

which would be much longer than

"Short_value"

These solutions would imply parsing all keys, check if they are present in the translation pack and compare them to the original English pack IF present + modifying the display.

That would be a heavy burden and speed loss for J!.

Case one could be considered if not slowing things too much, but looking at the discussion we had concerning JSON vs php ini rendering, I doubt it would be accepted.

The only viable solution IMHO is to teach Translators how to make their files and validate them if you provide the translations packs yourself.

When using Igevans Translation Manager or the to-be-finished com_localize, what you describe is easily solved.

These components do not let absent strings as the key is added and automatically populated with the original version (English in most cases).

It implies that translation files have to be updated when new keys/strings are added in the extension. That is the basics.

Breaking display if the strings are missing or uncorrect is a good way to push people to get their translations updated either by correcting themselves or getting it done by feedback to the original developper or/and translator.

When updating an extension, adding in the changelog the keys and location of the keys in the language files is a good idea.

OT: the main reason why we have been still adding missing strings in 1.5.15 in latest versions was the fact that some keys are written in clear English text, thus making it harder to spot and correct. That is one the reason I support the new format. The non-collison is another as it should let translators more easily adapt the values to the context.

-- 

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! Translation Coordination Team 

[JM Simonet]

Sure! ;)

[JM Simonet]

Yes, this is an interesting proposal indeed.
It would let trace a bit more easily where in code is the key.
Adding

NAMEOFCOMPONENT_PARAM_LABEL_WHATEVER
NAMEOFCOMPONENT_PARAM_DESC_WHATEVER
NAMEOFCOMPONENT_PARAM_OPTION_WHATEVER

which would give for Tiny, if we speak of the xml only:
PLG_TINY_DESCRIPTION
PLG_TINY_PARAM_LABEL _FUNCTIONNALITY
PLG_TINY_PARAM_DESC_FUNCTIONNALITY
PLG_TINY_PARAM_OPTION_SIMPLE
PLG_TINY_PARAM_OPTION_ADVANCED
PLG_TINY_PARAM_OPTION_EXTENDED

[Phoca]

Hi Jean-Marie,

seems like you are right, the performance (speed of loading the
strings) is more important than partially solved problems caused by
not complete translation. The same with long strings. In some case,
cutting only extension's name doesn't help preventing displaying long
strings.

2009/12/31 JM Simonet <infog...@gmail.com>:

> Yes, this is an interesting proposal indeed.
> It would let trace a bit more easily where in code is the key.
> Adding
>
> NAMEOFCOMPONENT_PARAM_LABEL_WHATEVER
> NAMEOFCOMPONENT_PARAM_DESC_WHATEVER
> NAMEOFCOMPONENT_PARAM_OPTION_WHATEVER
>
> which would give for Tiny, if we speak of the xml only:
> PLG_TINY_DESCRIPTION
> PLG_TINY_PARAM_LABEL _FUNCTIONNALITY
> PLG_TINY_PARAM_DESC_FUNCTIONNALITY
> PLG_TINY_PARAM_OPTION_SIMPLE
> PLG_TINY_PARAM_OPTION_ADVANCED
> PLG_TINY_PARAM_OPTION_EXTENDED
>
>
>