Namespaces

I’ve been wresting with how to describe namespaces, expecially with respect to lexicons, and am wondering if the archictecture is confused or if (as usual) I am.

Here are some issues:

We don’t seem to be using namespaces for much when it comes to the lexicon. Maybe there are some plans for future use, but at the moment they seem to be mainly for slowing things down slightly and making life difficult for book authors.

- When you use "Export Lexicon" the namespace information is lost.

- When you use "Import Lexicon" you have to manually specify the namespace (and could easily get it wrong).

- Since you can create namespaces easily in Lexicon Management, the only use for System | Namespaces is to delete them. That’s kind of thin for a main menu item.

I had envisioned a hierarchical relationship (lang->namespace->topic) that mapped to physical files but no such luck. There are only topic files and nothing in the file system contains any information about the namespaces. /core contains the core namespace files but beyond that, namespaces seem to be ethereal as far as the file system is concerned. And it seems wrong to say that namespaces are divided into topics when topics can exist outside of namespaces and can be loaded into more than one namespace.

Here are some thoughts on possible courses:

1. Get rid of namespaces altogether and just use topics (encouraging developers to use a prefix for their topic names).

2. Leave namespaces out of the Lexicon Management grid entirely but automatically create a namespace for each add-on using the lower-case name of the add-on.

3. Put PHP comment tags in the topic files that identify namespace sections.

Just my $.02.

A namespace divides topics into logical partitions and is very important. It doesn’t have a filesystem equivalent because lexicon topics that are distributed with specific add-ons or extensions will be in a namespace for that add-on. Further, namespaces are likely going to be used by add-on developers more as more complex add-ons are developed, and they will gain additional purposes beyond their original intent of partitioning lexicon topics.

Think namespace --> language --> topic, then the core namespace is represented by the core language files directory, i.e. core/lexicon/ or core/components/foo/lexicon/ for the component foo.

Also, namespaces could contain multiple add-ons, so using the add-on name would not work.

Quote from: OpenGeek at Aug 24, 2009, 07:26 PM

A namespace divides topics into logical partitions and is very important. It doesn’t have a filesystem equivalent because lexicon topics that are distributed with specific add-ons or extensions will be in a namespace for that add-on. Further, namespaces are likely going to be used by add-on developers more as more complex add-ons are developed, and they will gain additional purposes beyond their original intent of partitioning lexicon topics.

Think namespace --> language --> topic, then the core namespace is represented by the core language files directory, i.e. core/lexicon/ or core/components/foo/lexicon/ for the component foo.

Also, namespaces could contain multiple add-ons, so using the add-on name would not work.

This comment in the modlexicon.class.php file (for the load() method) is what started me down the wrong path in my thinking:

/**
* Loads a variable number of topic areas. They must reside as topicname.
* inc.php files in their proper culture directory. Can load an infinite
* number of topic areas via a dynamic number of arguments.
*
* They are loaded by language:namespace:topic, namespace:topic, or just
* topic. Examples: $modx->lexicon->load(’en:core:snippet’); $modx->lexicon-
* >load (’demo:test’); $modx->lexicon->load(’chunk’);
*

That clearly suggest a language -> namespace -> topic hierarchy.

Then there are these:

- The Lexicon Management grid has it Namespace -> Topic -> Language.

- In the lexicon_entries table, it’s Topic -> Namespace -> Language.

Note that none of these three is in the order you suggest (although I think there are a couple of permutations we haven’t used yet).

No wonder I’m confused.


At first glance, it looks like there are a crapload of many-to-many relationships here. I’ll see if I can wrap my head around it.

Well, if you want to simplify and clarify, it boils down to just "namespaces of lexicon entries (aka language strings), divided into topics and available in multiple languages"; there is no one-dimensional hierarchy other than between a namespace and it’s topics or a topic and it’s entries. Language is determined separately first (e.g. in modX culture initialization), then within a script you load a particular topic from a particular namespace to make your entries available, in that language. But you will sooner or later want to get an entry from a different language, and/or namespace, and/or topic than what is already loaded, and that is why load() follows the parameter structure it does.

That helps, thanks. It’s more complicated than I had thought (or I’m being particularly dense).

Are there restrictions on what can exist in the master lexicon at one time (e.g. only one language at at time)?

What’s the role of the manager_language Setting in lexicon->load() and lexicon(’key’)?

Quote from: BobRay at Aug 25, 2009, 06:55 PM

Are there restrictions on what can exist in the master lexicon at one time (e.g. only one language at at time)?

I don’t think so; you just need unique entries (the keys) within each namespace + topic combination.

Quote from: BobRay at Aug 25, 2009, 06:55 PM

What’s the role of the manager_language Setting in lexicon->load() and lexicon(’key’)?

manager_language is really just a legacy system setting from 0.9.x/1.0.0 and still used so you don’t need a plugin to determine the cultureKey when accessing the mgr context. That probably isn’t where that code should be, but it works for now.

As for lexicon(’key’), I’m not sure I understand that part of your question or what it refers to

Let me back up here and ask two questions:

First, if I wanted to change the language used in my Manager to French, what steps would I have to take?

Second, am I correct in saying that if I wanted to show both English and French language strings on the same page, (say, for a Canadian site), I’d have to load both languages manually into the database with "Import Lexicon" and then, either have no duplicate keys between the two, or switch back and forth using lexicon->load() for each string?

Quote from: BobRay at Aug 26, 2009, 02:16 AM

First, if I wanted to change the language used in my Manager to French, what steps would I have to take?

You would set a manager_language user setting to fr, and likely you’d need to log out and back in.

Quote from: BobRay at Aug 26, 2009, 02:16 AM

Second, am I correct in saying that if I wanted to show both English and French language strings on the same page, (say, for a Canadian site), I’d have to load both languages manually into the database with "Import Lexicon" and then, either have no duplicate keys between the two, or switch back and forth using lexicon->load() for each string?

That’s a great question, but I’ll probably have to defer to Shaun (when he returns from his honeymoon); IMO you should be able to load and access the same keys from multiple languages in the same request without unloading the previously loaded, but I do not know the answer off the top of my head...

That helps also. I’ll try to remember to bump this when Shaun gets back.

It looks to me like MODx knows automatically where to get all the necessary language strings in the manager_language language for the core namespace but not other namespaces. Is that right?

Is the main function of namespaces, when used with the lexicon, to prevent key collisions with same-named keys in other namespaces?

Quote from: BobRay at Aug 26, 2009, 02:16 AM

Second, am I correct in saying that if I wanted to show both English and French language strings on the same page, (say, for a Canadian site), I’d have to load both languages manually into the database with "Import Lexicon" and then, either have no duplicate keys between the two, or switch back and forth using lexicon->load() for each string?

Ugh, you’ve exposed the main problem of the Lexicon structure to date. The answer is that you’d have to switch, and let me explain why:

The current Lexicon API, when load() is called, basically just reads the collection of Entries for that Topic into an associative array, which is found here as a private var:

$modx->lexicon->_lexicon - An array, like _lexicon[key] = value.

So when a new Topic is loaded, it stores the array of strings into the main _lexicon array. It doesn’t store what Topic they came from. This allows me to "share" lexicon entries from different topics; or override existing entries.

However, if you note, this causes a couple problems:

1) There’s no separate array for each language. Now that I think about it, that could easily be fixable; just nest the topics inside a language-specific array. That would fix your switching problem. You would, however, have to manually load the language (if by tags, using the &lang=``) attribute for each secondary language entry you want.

The other problem, which I’m not sure *is* a problem, is:

2) If a 3PC loads a Topic that has an Entry with the same key as a core lexicon entry, it overrides the core Entry for that page. This might not be much to worry about, though.

Anyway, that’s my thoughts. on that.