Lexicon Madness (again)

A Lexicon is a MODx object into which you can load a set of language strings, divided into various namespaces and topics. Once loaded, the language strings can be retrieved by their keys and displayed in the Manager or on pages in the front end.

The Lexicon is the "dictionary" of loaded strings in whatever namespaces, topics, and language( s ) they were loaded from. Typically, in a single request, this lexicon will be loaded from a single culture indicated at the beginning of the request, though it is possible to load strings from various cultures as needed, on demand.

IMO, it should be "Culture", as the region and/or script information is not really conveying just Language, but potentially something more specific.

IMO, it should be "Culture", as the region and/or script information is not really conveying just Language, but potentially something more specific.

I don’t have strong feelings either way. "Language" is a more familiar term and, IMO, easier for new users but, as you say, somewhat inaccurate. I thnk, technically speaking, that en-uk and en-us are "forms" of the English language (called "American English" and "British English"). American English includes all "dialects" used in the US.

OTOH, francais and francais-utf8 aren’t really different "Cultures." So there’s no perfect solution for us. I think it’s common to see "What language is it written in?" answered with "American English" so I’d probably lean toward using "Language," especially since "Culture" includes so much other stuff that has little or nothing to do with Lexicons or MODx.


My main concern is that if we’re going to change to "Culture," the sooner we change it in the Manager, the better.

But if you want to call it Languages all the way around in the manager, I don’t have a problem with that; as long as the developers know the code refers to it as Culture. Personally, I think the Culture/Language help differentiate the parts of the core involved in the i18n features of Revo.

I dont think it’s too much of a stretch to say that the date and time formats are part of the language (along with ltr, rtl and other differences). It will be a lot easier to explain that to developers than to make it clear to newbies what we mean by "culture" since they think of that word as including religion, food, art, daily customs, music, etc.

[EDIT] I just re-read your message and want to make sure we’re talking about the same things. I was primarily referring to the "Language" term on the lexicon screens. I wouldn’t want that changed to "culture."

When you talk about "culture," (as distinct from lexicon language) how is that specified by the user/developer?

The other is the use of "lexicon" in the manager. My feeling is that the term "lexicon" should be reserved for the service (can I call it an object?)

In the manager and some docs, however, lexicon is sometimes used for any collection of langage-related key=>value pairs. In "Import Lexicon," for example, it’s used to refer to a topic file, which I think is quite misleading.

The manager also refers to "lexicon strings" in several places, which I can live with but would rather call "language strings" because they exist outside the lexicon until they are loaded.

I’d also like things a lot better if there were a simple, automatic mapping of Lexicon stuff to physical files, which there definitely isn’t now. That way, MODx could look in the files if a language key wasn’t found in the DB and you could easily back up, restore, and update the lexicon_entries table without any manual intervention.

I’d also like things a lot better if there were a simple, automatic mapping of Lexicon stuff to physical files, which there definitely isn’t now. That way, MODx could look in the files if a language key wasn’t found in the DB and you could easily back up, restore, and update the lexicon_entries table without any manual intervention.

Hm. How would that work? The idea of having it in a DB is so it can be editable; making it file-based removes that functionality (see: Trying to change a language string without hacking core in Evo).

So are you suggesting that if a lang string isn’t found, that it should search the corresponding file? Should it do this every time it doesn’t find a string? This might cause some latency...hm. What do you think?

/lexicon  /* or core/lexicon/ */
   /core
      /en
         topic1.php
         topic2.php
      /fr
         topic1.php
         topic2.php
   /namespace2
      /en
         topic1.php
         topic2.php
      /fr
         topic1.php
         topic2.php
   /namespace3
      /en
         topic1.php
         topic2.php
      /fr
         topic1.php

  
   /country
      en.inc.php
      fr.inc.php