[Revo Terms] Lexicon

BobRay not that it is correct, but do not almost all php cms applications refer to their "lexicon" as language files? I think that while incorrect and inaccurate it is commonplace. Its like the fact that the most efficient place to put navigation on a website is on the right but since people read left to right in most countries it isn’t because they SEE the nav on the left.

I agree with all your points but I still claim that user conventions and commonalities--be they wrong or inaccurate--most often trump the correct or proper in user studies, whether it is interface design or terminology or grammar (although that one is hard to admit.)

This is not dumbing down or reaching to the LCD it is about building on conventions.

Now that I’ve said that I do agree with you BobRay that in this case we should break convention and make this an education point because of one fact. The lexicon is a higher level implementor element. End users aren’t going to be banging around in the lexicon/language file/dictionary it will be developers and more advanced site builders. We don’t need to communicate what the lexicon is to end users and most quick and dirty site builders will likely never play with the lexicon. (I’ll rarely use it).

Quote from: BobRay at Oct 10, 2008, 07:02 PM

... the collection of phrases we use to communicate with the user in a particular language ... is not really a language. It is, in fact, a lexicon, which is a sub-set of words in a language used for a particular purpose.

A language has a grammar and syntax rules..

Your definitions are correct, but I think you’re looking at this from the wrong angle. When a developer creates a set of text strings and saves them in a set of files in the MODx lexicon system, he/she is neither defining a language (a vocabulary and set of rules) nor a lexicon (a context-specific vocabulary), rather he/she is choosing a language in which he/she wants his/her software to be able to communicate with users.

Another way to say it is that the "lexicon" is fixed by the set of text strings that a piece of software needs to be able to display. All this discussion about lexicon/language files/functionality is that we want our software to be able to display a given set of terms in multiple languages.

I think the truest "lexicon" within the MODx system is the set of internal variable names to which the text strings can be assigned, since they don’t change regardless of which language the user chooses. I also think that when a developer is creating language files, or a user is making a choice, they’re not thinking "what set of terms do I want to be able to display", rather they are thinking "in what language do I want to be able to display the terms I have".

Does any of that help our thinking?
--Bill

Quote from: myfriendscallmebill at Oct 11, 2008, 03:04 AM

When a developer creates a set of text strings and saves them in a set of files in the MODx lexicon system, he/she is neither defining a language (a vocabulary and set of rules) nor a lexicon (a context-specific vocabulary), rather he/she is choosing a language in which he/she wants his/her software to be able to communicate with users.

My point was that when the developer does that, he/she is definitely creating an object in MODx and that object is absolutely not a language, even though the developer has to choose a language first.

In fact, the developer doesn’t even have to do that. A single MODx lexicon entry could contain strings in multiple languages if the developer chose to do it that way - say for multilingual menus, e.g.:



Though I don’t actually know how spanish- and french-speaking developers actually refer to a "home page."

I also think that creating "a context-specific vocabulary" is exactly what is being done. It’s a set of terms and phrases to be used in the specific context of the site being created.

Hopes for something normal humans can understand: dashed.

"Multi-variate lexical object instantiation tools" it is.

All joking aside, I agree with Bill, and was glad to see Jason leaning towards, making this part of the manager more understandable for common day-to-day tasks and initial learning curve. Thanks for making a great suggestion.

The intricacies of Lexicon management and what "extra stuff" can be done behind the scenes are something developers shouldn’t have a hard time understanding. Their lexical mojo is simply evidenced under the Languages menu in the Manager. I don’t think we’ll have tragic repercussions or pose any detrimental risk to developer adoption making this choice.

Back to my lame analogies: it’s similar to TVs in 096. They’re simply extra content fields—but you can do so much more with them. Developers can build some very interesting solutions like a dynamic tagging, input and output widgets, etc. Most end users wouldn’t understand that Dynamic Tagging involves building an array of options based on the existing values via a MySQL query, transforming a text-input box via Javascript into something that looks like a simple tag chooser, and that upon save actually stores the contents as an array in the DB is just another flavor of TV. Developers I don’t think have a difficult time connecting the complexities of what’s going on behind the scenes to the end-user label of "Tagging TV".

The lexicon/languages part is an area of Revo with which end users will interact; the more we can do to make it intuitively understandable, the better. "Lexicon" to my simple mind just comes across as so much more complex, and behind the scenes it is (like TVs). Now consider that in light of a transition from 096 to Revolution.

"You mean I have to know how to do all that stuff that in order to use MODx? ... *blink* ... Think I’ll keep looking for something I can use. I’m not a developer.", says the poor, frightened marketing lackey (that would be me, btw).

In all fairness we have repeatedly reinforced that Revo as an awesome tool for developers, and again it is. Making the terminology around it in the manager overly (but accurately!) techy can only add to this perception. Most people think developers != end users. If this is an area that would we could compromise on for the end-user sake, then please let’s do! Individually the words we use for different things are no big deal, but collectively they might create a mental block that’s needlessly difficult to break down. My concern is that we might alienate some of the great community that put modx on the radar screen.

As I discovered, if you ignore anything that’s been said about Revo and just try it, it becomes quickly apparent that it’s simply modx, only much better for managing and creating maintainable content. By a long shot. But for anyone that has had kids and attempted to get them to try new vegetables, you understand what it’s like. Human nature in many cases makes people resistant to things with which they are not comfortable or that they perceive may create discomfort/change/difficulty/confusion/complexity (pick one or all). If we can reduce those perceived barriers or even eliminate them, then the entire community wins. Developers have a large user-base to sell services to, and end-users get a superior system that’s faster to learn.

Language is already used in Revo (there is a Language table), though I think it should be called Culture, cause Language isn’t specific enough.  This differs immensely from the Lexicon, despite it’s relationship.  And you know what...

Can we please just stop arguing about this one? I don’t feel this is productive now.  It’s not going to change; if you want to create a layer of marketing words to simplify how I talk about this code, which is through the metaphors I used to write it, great.  But right now I need help strengthening or extending these metaphors for the developers and linking them to whatever easy concepts will make it attractive to these developers to create things people that want something without having to use their brain will want.  Otherwise, I don’t see any of this banter as helpful dialog; the time would be much better spent on asking questions on why this is called such and such, what it does, and making documentation so developers can understand these metaphors properly, regardless of what it is called and whether you think it should be something else.  Without this, we won’t have any developers producing components for these folks anyway.  The fact is, these things have been called what I called them for almost 2 years, and I’m not going to just change them at the last second before we release it.

Looking forward to some help documenting these concepts to help both developers and non-developers understand Lexicons and how they relate to Language/Culture.

Agreed, although I’d like to put in a vote for keeping "language" as opposed to "culture" since, for example, British English can legitimately be considered another language and "culture" has so many other meanings (and I’m not looking forward to typing $_culture in the source files).

Quote from: BobRay at Oct 11, 2008, 10:40 PM

Agreed, although I’d like to put in a vote for keeping "language" as opposed to "culture" since, for example, British English can legitimately be considered another language and "culture" has so many other meanings (and I’m not looking forward to typing $_culture in the source files).

As long as we understand that languages "can" represent regional-specific dialects, i.e. more than just a language code.

BTW, all Languages in Revolution should be named using the "best current practices" for HTML/XML language tags identified as BCP47. This will allow (in the future) for the Lexicon to inherit strings logically when providing a small set of overrides for a very specific region or script tag. IOW, you could provide a full translation for Spanish with a "Language" record named es, and a subset of overrides for Spanish as spoken in Columbia with a "Language" record named es-CO.

Since we will also want to associate other features of Localization into Revolution using these "Language" records, I thought it would just be more appropriate (and accurate) to call it "Culture" as I have referred to it in the core code. But I’m fine with it remaining Language with that thought in mind.

Languages works there since OSs and most apps distinguish between en-uk, en-us, en-ca as languages not cultures.

Great! This has been fantastic input. I’ll definitely work on renaming some things in the manager to make it more user-friendly, and we can keep the term ’lexicon’ for developers.