[Revo 2.0.7-pl] I can add Lexicon, but can't search or modify it

Hello guys,

First of all, I’m using MODx in Japanese environment.

I’ve installed packages like FormtIt or SimpleSearch, and noticed they didn’t have Japanese translations.
Then I tried to add Lexicon from "System" - "Lexicon Management" - "Create Entry" like this.



I could add this key/value correctly, and could see this from phpMyAdmin.
However, I can’t update or delete this entry through MODx because I can’t find this entry.

I expected if I wanted to search or update this, I should select "formit" from Namespace, "ja" from Languages.
but "ja" can’t be displayed in Language tab.

I suspect this is a bug. any thoughts ?

Did you try selecting the default topic? I think you need to select it even though it already says default. Also, note that there may be multiple pages of language strings.

Thanks for your quick reply.

> Did you try selecting the default topic?

Yes. After adding custom entry, I tried to search it by selecting like this.

Namespace: formit
Topic: default (just in case, re-selected)
Language: (I’ve added ja, but ja can’t be displayed)

> Also, note that there may be multiple pages of language strings.

There is only 1 page. cs,en,de,fr,ru,nl.

In your environment, can you search/update your custom ja(or other) entry ?

I can do it for the core, but of course I don’t have a ja language for FormIt. It may be necessary to have an actual language file in order to add or edit entries.

You might try this:

Go to core/components/formit/lexicon and copy the en directory to create a new ja directory.

Then edit the language strings in that ja directory.

Thanks for your reply again.

Actually I got a same workaround from another user. its solution was like this.

(creating dummy entry for ja by copying en. don’t need to edit files inside)
# cp -a core/components/formit/lexicon/en core/components/formit/lexicon/ja

Then the key/value were displayed at "system" !

Does someone know this is correct behaviour or bug ?
I’m guessing if this is correct behaviour, every snipet developers have to prepare every language directories.

Quote from: nomo at Feb 19, 2011, 12:02 AM

Thanks for your reply again.

Actually I got a same workaround from another user. its solution was like this.

(creating dummy entry for ja by copying en. don’t need to edit files inside)
# cp -a core/components/formit/lexicon/en core/components/formit/lexicon/ja

Then the key/value were displayed at "system" !

Does someone know this is correct behaviour or bug ?
I’m guessing if this is correct behaviour, every snipet developers have to prepare every language directories.

I think it’s expected.

It’s assumed that if you wanted a ja translation, you’d follow the steps I listed above, then contribute the file so that it could be included in the FormIt package for other users.

> It’s assumed that if you wanted a ja translation, you’d follow the steps I listed above,
> then contribute the file so that it could be included in the FormIt package for other users.

Hmm, it makes sense.

However, on the other hand, I understand one of the purpose of Lexicon management is it’s easy to create international lexicon which isn’t supported by default.
If I had to prepare translation files, I’d just edit these files instead of Lexicon management.

In addition, it’s not beautiful because entry can be added from management interface, but can’t be modified or deleted forever.
That’s why I’m still thinking this is kind of a bug. (please correct me if I’m wrong)

Once you create the file(s), you should be able to modify any of the strings in Lexicon Management. The changes would survive any upgrades of MODx or an add-on component.

Ideally, you could create the strings as you tried to do to. That may be the way it’s supposed to work, so it could be considered a bug. If not, it’s a feature request.

Thanks for your reply again.

> Once you create the file(s), you should be able to modify any of the strings in Lexicon Management. The changes would survive any upgrades of MODx or an add-on component.

Yeah, I know.

> Ideally, you could create the strings as you tried to do to. That may be the way it’s supposed to work, so it could be considered a bug. If not, it’s a feature request.

Now I can add or edit custom entries, but I guess many modx users will be confused when they’ll do the same procedure in future.
I believe it should be resolved.

I created new ticket. Bug #3884

Thanks!