[SOLVED] Creating settings lexicon translations for add-on components

Hey guys.

I’m trying to create a simple translation for one of my setting keys but I’m not having much luck. I followed the example provided by Shaun (and thus Quip) in the RTFM, but no cigar (yet).
http://rtfm.modx.com/display/revolution20/System+Settings

It says that each key is matched on setting_{key name} and setting_{key name}_desc. While I have those, the translation does not match up. I found it in the lexicon management and when I change "Caching" to "Caching" it shows up but when I change it back, it defaults back to setting_component.keyname. So, the lexicon matches up but only when it’s changed. Back to default is defaults to the technical lexicon reference.

Now, I tried creating the lexicon and then creating the setting (and vise versa) and even that didn’t work. I’d imagine it to be loaded into the manager, but for the whole idea of it I’ve also written a plugin that loads the component:default lexicon. Still, it should work.

So, what am I doing wrong here?

And oh yea, my default.inc.php loads, as said before and is picked up by the Lexicon Management. The two lines I need are (for example);



Tx in advance.

Make sure your Namespace for your component matches the installed components dir for that component, eg: {core_path}components/quip/ This should be done if you called this line in your build script:



Also, the settings keys have to be in the default topic in your lexicon. They also have to be in the format:



Also, if you’re working on these while running the same mgr, make sure to change the setting ’cache_noncore_lexicon_topics’ to No.

Thanks for the speedy reply Shaun. I’ve already got all Lexicon (and JS) caching disables, so that shouldn’t be the problem. Upon changing the Lexicon in the Lexicon Management and then clicking the reload tool of the ExtJS Grid, the string updated to "Caching!" so that points to non-core lexicons working perfectly - aside from not being displayed as default with default content.

The package I’ve got going on hasn’t been installed through Package Management, since I’m developing it within MODX. I’ve added all Namespace, Action and Menu specifcs by hand, which we also did with VisionCart back in the day.

Since the still classified nature of the component, I can’t give away too much at this time, so for future reference I’m going to address it as "component".

I’ve got a {core_path}components/component set up as a namespace with the component name and the duplicate folder structure used in Quip, VisionCart and all my other MODX projects. Currently the setting has been set up like so:

Key: component.cache
Name: setting_component_cache
Field type: Yes/No
Namespace: component
Area Lexicon Entry: caching
Value: No (0)
Description: setting_component_cache_desc

In my default.inc.php I’ve got both cases to catch any of them:



Now, when I go into the Lexicon Management (namespace: component, topic: default, language: en), the first 2 are green lit and I had to "Revert" the entry to it’s default state, which was set in the default.inc.php. The fun part is, both show up there but still are not loaded to replace the default technical term in the settings by the more human formar "Caching" (or Caching 2).

So, what’s going wrong here?

Oh yes! I checked the database "modx_lexicon_entries" and it contains 2 entries at this time, the setting_component.cache and setting_component.cache_desc. Strangely enough, the value is exactly the same but the one point (".") is replaced by an underscore ("_").

-- 16:22 / 2nd of August
I’ve bugtested some of it, and when I add a setting like I described above, it still creates a Lexicon entry in the database. When I delete those 2, it works! What the ?! So, I reckon when I use it to install it, it doesn’t use the default functionality provided by MODX and I’ll be safe from this?

I’m not going to mark this as SOLVED yet as I am not sure if this is a correct behaviour.

1. Don’t use the MODX manager to create lexicon setting descriptions for your Settings. When you enter it in through the Add Setting window, it’s going to automatically add modLexiconEntry objects with "setting_component_cache_desc" as their *value*. It does this to allow ad-hoc settings and translations. However, you don’t want this. MODX automatically handles this, so you can leave name/description blank. If you do add it through the Settings grid, just leave name/description blank.

Remember, entries in the modx_lexicon_entries table (modLexiconEntry objects), are for meant for *overrides* of existing file-based lexicon entries.

2. For example, here’s a Quip Setting in my Quip build script:



And then in core/components/quip/lexicon/en/default.inc.php:



Note how I haven’t even touched the "Add Setting" button on the Settings grid. The build script will install the setting when I install Quip.

Also note how I leave the "." in there, since the *key* of the setting is "quip.emails_from_name" - I want this to match in the lexicon key perfectly.

For your situation, i’d look in your ’modx_lexicon_entries’ table and clear out any settings with the key "setting_component.cache" or similar.

Exactly the behaviour I was expecting and the most logical one at that.

I didn’t use the Manager to create Lexicons, they were automaticly added when I added a setting through the GUI, which would be wrong in my case.

When I copy the build functionality from Quip I reckon all will be fine! Thanks for the help Shaun, saved me a huge chunk of time!

*SOLVED*