Help with custom Phrase

[dweyer]

Hi There,

I have create a new phrase and added it to the following templates by adding <{$language[disclaimer]}> in the relevant places:
email_autoresponder
email_staffreply

and all works great. I then added it to email_staffnewticket but this time no joy, the custom phrase will not show up. I have included the exact text from the template and would appreciate it if someone could let me know if I have added it to the incorrect place or something:

<{if $ishtml == true}><font face="Verdana, Arial, Helvetica" size="2"><{$contentshtml}><{else}><{$contentstext}>

<{$language[disclaimer]}>
<{/if}>

Thanks
Dill

[supportskins]

In Kayako somehow not all phrases work in emails. Something Kayako needs to look into.

[Jamie Edwards]

If this is the case, please submit a bug report.

[dweyer]

Well Jamie, thats why I posted for help as I just wanted to make sure first that it wasnt something I was doing wrong. Would you suggest that in the mean time I just add the text manually to each template rather than use a phrase?

[supportskins]

Would you suggest that in the mean time I just add the text manually to each template rather than use a phrase?

Yes that would work.

[John Haugeland]

This may be an issue of string caching. I have opened a new bug to track this matter.

Kayako Bug Tracker - Viewing Issue #666 - Template strings apparently sometimes "don't work"

At this time I have virtually no information regarding this defect. Customer comment, especially reproduction steps from a blank desk, would be extremely valuable in recreating this problem.

[Dewak]

Have you tried rebuilding the cache?

I have personally noticed that when entering custom phrases, the MySQL fetch of the phrases doesn't work properlly, I don't know the reason but you have to go back to the Admin CP and update the phrase. This has worked for me in the past.

Best Regards

[John Haugeland]

Not that kind of cache. Sorry, I probably should have been more detailed.

The string loading mechanism in SS caches strings in blocks according to what a page is known to need beforehand, to keep disk access and ram requirements low. If the custom string isn't added to a block that gets loaded in such a fashion, it wouldn't be available to the dependant template.

Mind you, this is a hypothesis, not a diagnosis, hence the bug tracker entry.

[supportskins]

John,
Thanks for the clear explanation. I will keep a track of the bug.

[John Haugeland]

Again, it's a suspicion, not a diagnosis. I am not saying this is certainly the problem, just that this is what my gut says.

[Ryan Lederman]

I have closed this bug in the tracker. Please refer to the following comment I left there:

===============================
Not a bug; let me describe here how the language/template systems are tied together.

Language strings are stored together in groups. The group boundaries are defined by files. For example, one group of strings would be /locale/en-us/tickets.php. This file would contain all of the strings necessary to render pages related to tickets.

In the source code, groups of language strings are delay-loaded, meaning that they are only loaded when required. The function that does this is called loadLanguageSection().

When individual templates are echoed by the system, only certain language "sections" or "groups" are loaded into the template driver before the templates are processed.

This means that when you add new language strings through the Admin CP, they are not assigned a specific "group" and thus are not loaded by the template driver before displaying the template. This is why the strings appear to "not work."

There is a solution, however:

Grep the source tree for the name of the template that you wish to add a string to. You should see a line such as the following: "echo $template->displayTemplate("name");" Look up above in the file for a line that looks like "$template->loadLanguageSection("foo");" "foo" is the name of the "group" that you want to add your string to in order for it to be loaded up and displayed by the template.

Manually edit the database record that contains the language string. The table name is "swlanguagephrases." Find the record containing your new language string and change the "section" and "code" columns. The "section" must be set to the "group" that the string should reside in, and the "code" needs to be set to "group:id" where group is the name of the group of strings and id is the string's identifier. (e.g. "tickets:mystring"). Your string will now be loaded with the rest of the strings in the same group, and will appear in the template in question.

[supportskins]

In that case can you not change this request as a "Feature Request" making the software automatically add the newly added phrases from the Admin CP to the software language groups rather then there being a need to manually editing the software files and database.

[Ryan Lederman]

I've created a new bug entry: Kayako Bug Tracker - Viewing Issue #685 - Adding language pack entries does not allow for selection of the "section" in which the string should be inserted.. This bug is assigned to the 3.20.02 build.