Edited Language file but some titles not changed

8 years 6 months ago #7 by Krzysiekwro
I turned language debug on before posting a message there and funny thing is that even if I overwrite strings in GB version still nothing changes.

Please Log in or Create an account to join the conversation.

8 years 6 months ago #8 by geoffc
I think there is something wrong with the language file. Exactly what I have still to discover.

The file is being read and strings in the file are being used for the display, its just that some of them are not displaying for what ever reason.

What I have found is that you can create a language override for one (or I suspect any) of the offending strings and this is then displayed correctly. So for example I created a language override for the COM_ISSUETRACKER_FIELD_ISSUE_SUMMARY_LABEL string and the correct language is displayed on the form. I used your string translation in the override

This tends to indicate to me that the problem is not on the specific line that the strings is on but on one (or more) of the other lines. I an wondering about diacritics, but am undecided at present as to whether that might be the problem.

Regards
Geoff

Please Log in or Create an account to join the conversation.

8 years 6 months ago #9 by geoffc
There is something very strange going on here. Its certainly not the same type of problem previously seen and I haven't seen it happen with other translations. I will carry out some more tests to be 100% sure its only this PL translation that is affected.

First in answer to your question where the introductory text is specified, this is a component configuration parameter. You can enter what ever text you desire in the parameter. It was done this was for those not familiar with language overrides. This is likely to change in release 1.7.0 which supports multilingual sites.

I agree with your observation that changing the GB file also didn't change these 'problem' strings. Not sure what is going on, since it must be getting the text from somewhere. I have no cache in use, which is where one expects these problems to arise from, and it certainly isn't getting it from the admin language file either.

There are no parsing errors reported on the PL file. It is in the correct UTF (without BOM) format. Some (most) strings are picked up correctly from the PL file, just a few which are not and these look absolutely fine to my eyes.

Ongoing. This is not going to be an easy one to crack.

Regards
Geoff

Please Log in or Create an account to join the conversation.

8 years 6 months ago - 8 years 6 months ago #10 by geoffc
I know what the problem is and I know how to fix it, but this is only by trial and error.

The front end form uses the inbuilt supplied 'Joomla JForm' to create and display the fields. There appears to be a limit on the size of the language key string that one can use in the 'label' and 'description' fields. Not the translated language string but the 'key' itself.. I have searched everywhere but have been unable to find this specified anywhere, however it seems to be set to around 40 characters. The strings that we are having problems with all have a length that exceeds this limit. i.e. COM_ISSUETRACKER_FIELD_ISSUE_SUMMARY_LABEL ( 42 chars), COM_ISSUETRACKER_FIELD_ISSUE_SUMMARY_DESC ( 41 chars) etc.

This limit does not seem to apply if a language override is created and used. Go figure! It also didn't seem to make a difference for the default en-GB strings either! That is my excuse for never having seen it before. I am surprised that nobody else has seen it though,

There is nothing wrong with your language file at all!

The solution is for me to reduce the size of these strings used in the forms so that they are below this (unspecified) limit. i.e. Edit the itissues.xml file, and associated language files.

I will make this change in the next version. In the meantime a language override will enable you to display the correct strings on your front end. Fortunately we do not have more than a dozen (estimated) strings to create in this way. Not ideal perhaps but gets one over the immediate problem.

Regards
Geoff
The following user(s) said Thank You: Krzysiekwro

Please Log in or Create an account to join the conversation.

8 years 3 months ago - 8 years 3 months ago #11 by chrisc
After much head scratching and testing the problem is a bit more complicated than first thought but we think we have an answer to the problem.

First if there is a language override set for the specific string then it is used in the display. So our suggested work around is fine and got one over the reported problem, but it was, as we said at the time a work around.

We always wanted to provide a 'better; and 'cleaner' fix. We originally thought that it was somehow related to the length of the string key, BUT we found a few cases of short keys that also showed the same problem.

It now looks as if it is related to the the key not being present in the foreign language admin language file. Exactly why we do not currently understand.

Consider the following specific case of the string COM_ISSUETRACKER_CREATED_BY. and the Polish translation. We do indeed find the translated string in the front end pl_PL language file but it is not shown in the displays as translated to Polish instead displaying it as en_GB. Looking at the back end we find the en_GB language file has the string but it is not present in the pl_PL admin language file. (To be precise it is present but commented out in the pl_PL file) If we add the translated string to the pl_PL admin file then the front end displays the string in Polish.

We have tried this with a number of 'untranslated' strings and in each case the front end display shows the translated string and not the en_GB string.

It is common to have the admin language files as a fall back in case a string is not found in the front end language file, BUT we have never before seen a situation where the string is present in the front end but the system insists on using the back end file.

We do not claim to be expects in multilingual language files but this behaviour is not one we would expect. What is does indicate is that the order that the language files that Joomla uses leads us to believe that the admin files somehow take presidence over the front end files even on the front end itself.

Aside We did try seeing if we could somehow catch the situation in code but the problem is that the translated string is 'picked up' even if it is not the intended language translation. Given the number of possible languages that may be available trying to catch this in code is no trivial task and it was decided that it was never going to work correctly.

If you could test out the problem by adding the 'untranslated strings to the pl_PL admin language files and seeing if that resolves the problem, then we have both a complete answer to the problem and a solution.

Regards

If you are using our extensions please leave a review at the JED: IP Mapping | Issue Tracker | JAudit | Password Control

Please Log in or Create an account to join the conversation.

Time to create page: 0.232 seconds
Go To Top

Joomla! Debug Console

Session

Profile Information

Memory Usage

Database Queries