[wiki] Textbook Terms and Terminology

saccade · 2008-12-23 11:12:13

Stupid me! Obviously – as you can see in the list – of all pages I exactly translated those at first, which didn’t have Bloke’s excellent images. So I simply didn’t notice that there already is a consistent way of imaging. So next time I’ll look twice.

saccade · 2009-01-08 17:15:14

Another proposal, regarding “lists of articles” (and other content elements) on content-panels.

As far as I can see, they are always called “list of …”. But there could be some mixing up with for example “linklist” or “file download list” or even a “list of articles” produced on the public-side (by article and just using the linked titles) – especially in translations.

So I’d like to have a term as unique as possible – which obvously is difficult.

In German I figured out the following possible terms for “list” (english congruent in brackets):

Liste (list)
Verzeichnis (register, directory > folder, table, list)
Tabelle (table)
Aufstellung (drawing up)
Katalog (catalogue)
Index (index)
Inventar (inventory)

As a term it should be a compound of the content type and one of these, e.g. like “Artikelliste”.
But “…liste” is not very specific and much to easy the same word as a type of content on the public-side.
So I first thought about “…verzeichnis”, but “verzeichnis” on the other hand in german is often the same as “directory” or “folder”, which both have to be at service for other descriptions (images folder or images directory).

So now I stick to “Katalog”. A catalogue mostly is exact the metaphor which is appropriate: It normally lists all things you have in stock (the primary view), it assigns numbers (ID#), can be presented in a sorted manner or a sub-part (a filtered list of …). And it has normally a definite set of information about the things (columns).

So at least for german I propose to use the term “…katalog” for the lists on content-panels as follows:

Artikelkatalog
Bilderkatalog
Dateikatalog
Linkkatalog
Kommentarkatalog

Maybe using “catalogue” could be an option for the english terms too?

What do you and others think?

Last edited by saccade (2009-01-08 17:18:55)

saccade · 2009-01-08 17:43:00

And a second proposal regarding changes in multiple content elements.

In all content panels you can change categories for multiple articles/images/files/links/comments (and do other things, e.g. delete) at once.

After trying to create an appropriate description of the handling, I think it would be more clear for a reader to have a common term for this function.

It could be a term reflecting the type of content, e.g. “edit multiple images”, “edit multiple files” – but even better would be a common term for all types, so we could have a general description.

My proposal of term for this concept: “edit multiple elements”.

Or is there another better word for elements? “content elements”, “content pieces”? Maybe “entries” (but this seems too ‘technical speak’ to me)?
“edit” because this better includes ‘changes’ and ‘delete’.

Also: In German this could be “Mehrere Inhaltselemente gleichzeitig bearbeiten”.

Or after all better use the type’s name?
E.g. “Edit multiple images” / (de) “Mehrere Bilder gleichzeitig bearbeiten”?

(I didn’t closely follow those thoughts yet in my contributions (in “Articles”, “Links”, “Images”) but those arise from trying a solution there. But you can see there what I mean.)

Evaluations welcome!

Last edited by saccade (2009-01-08 17:47:12)

Destry · 2009-01-08 21:42:36

Hi Saccade,

I like “content elements” as it makes it clear what kind of “elements”, specifically, as elements by itself could be vague to people if too far out of context.

P.S. I would just like to add that I think it is great you have taken active interest in the translation work and hold dialog on these things like you are doing. Truly great. I only wish more of the translation reps — or anybody — would do the same thing for other languages. It would be really interesting and positive in a number of ways. You should try and engage more German speakers in your efforts.

By the way, I got your email about the pages needing deleted. I’ve added you to the custom LangLeads user group (see Special:ListGroupRights, which is new group I created specifically for translation reps (that’s the new group now instead of making them wiki sysops) so you should be able to delete your own German pages now (you can delete any page, but it should just be those you are working on yourself, as necessary). Give it a try and let me know how it goes.

Last edited by Destry (2009-01-08 21:45:01)

saccade · 2009-01-08 21:53:48

Thank you!
It’s a great pleasure to contribute to textpattern and to its friendly community :-)

btw: I wish you all a happy new year!

I will try out the groupRights later this evening.

saccade · 2009-01-08 23:31:48

just to prove the concept: in Files I tried to follow the proposals.
Still think about “catalogue” instead of list.

And I add another proposal:
Sometimes the panel changes its view (but without an explicit message, what happened, see below) for presenting an edit dialogue, e.g. when editing the files properties or image properties or links properties.

Obviously there isn’t any noticeable indicator, where we are. The tab stays the same, there is no header, and only the title in the website’s header indicates something, but not too specific (and I personally don’t look there while working on a panel anyway):

active Panel	Title normal mode	Title edit mode
Images	Images	Edit image
Files	File	file
Links	Links	Links
Comments	Comments	edit comment

(Does this need some standardizing in the core?)

Edit (I forgot the proposal): In describing what happens I say “the panel view will switch to edit-properties-mode”. So I propose something like

“panel view”
“switch”
and “edit properties mode”

Last edited by saccade (2009-01-09 15:47:23)

saccade · 2009-01-09 08:18:24

@Destry: ListGroupRight work for me – and I hope not to make any mistakes :-)

Here the next proposal:

The “pieces of information” given to a content elemment (such as ‘description’ an assigned ‘category’ and like that) as far as I see are mentioned as “pieces of information” or “properties”.
In german that would make “Eigenschaften”.

What bothers me a little is, that this (“edit the properties of an image/file…”) easily could be mistaken as a files’ physical properties, e.g. ‘writable’ or in images the dimensions, color depth and like that. Or generally spoken: As to edit the content itself.
In german “Eigenschaften des Bildes bearbeiten” (edit the images’ properties) definitely will be understand as to modify the image itself and would lead to false expectations.

I looked for another term instead of properties=Eigenschaften but couldn’t find yet.
I think it has to be compounded in the following way (at least for the german side):

properties of the content element
(de) Eigenschaften des Inhaltselements

to make clear you can edit mostly the properties of the content entry.

Does this make sense? Is there a better solution?

Last edited by saccade (2009-01-09 08:19:19)

saccade · 2009-01-09 08:32:10

Next one:

pagination of lists of articles/images/files/links/comments if the list doesn’t fit on one page.
Is the term “pagination” common in english?
In German the correct one would be “Paginierung” but it is very uncommon, very technical language.

Also I think it would be fine to have a term for the pagination’s “pages’ navigation” with “previous/next”.
But “page navigation”/(de)“Seitennavigation” seems to general, because it could easily be mixed with the main navigation of panels.

Or simply summarize all under “pagination”/(de)“Paginierung” as a concept term and hope to coin/mint the term?

Destry · 2009-01-11 01:29:33

saccade wrote:

Is the term “pagination” common in english?

Pagination is a common enough word in English that when used, which is usually in context to technical topics, people know what it means. So, yes, it’s technical, but it’s an expected term in such cases and avoiding it is probably unwarranted. However, you could say “page navigation” or “previous/next navigation” and no meaning would be lost.

I’m sure you’ll come across many instances in all of this translation where you can’t make a direct match-up of the terms between two languages. That’s OK, you describe the concept being conveyed in the best terms for the language, and not get to hung up on the specific semantics. At least I find when translating French to English (the only way I can go, oddly enough), I can often not make direct translations of words and expressions. French is pretty wordy at times. :]

saccade · 2009-01-11 12:45:48

German also often is a lot more text to tell the same thing. I love my language, but I also like to express things as short and tight as possible – the only reason why I write lenghthy thoughts about the right terminology (sorry for that, but I can’t help). You have to work it out, then it will fit a broad range of tasks. But regarding briefness I’m sometimes a bit jealous at the english language. ;-)

On the other hand I have in mind that the TextBook articles should be helpful not only for developers of websites and designers, but also help people who are quite fresh in this area to understand the basic concepts (even if they only look for a how-to in a special case) – especially the content-pages should be helpful for mere author-users. For this reason I described some things more in depth on the pages I edited.
For someone who starts webdevelopment for the first time and begins textpattern there is a chance to lay solid foundations of webstandard-conform concept and logic (e.g. hardcode links or regard them as content elements).

As a student I worked as a proofreader for software manuals and tutorials (commercial books of a publishing house) and read hundreds of them. I often noticed where there is a point, where a user will loose the thread. (sometimes – very seldom – I even could improve something – but please don’t blame me for the other, I only had to proofread very fast, not to lectorate). So I developed high demands on manuals, which is why I like to help Textpattern get a very good one.

Direct match-ups of languages aren’t what I look for, but I like to have the very best word in a language for a worked through concept of explaining things. Sometimes it’s also a question of how to interpret or read a thing. If you have a reasonable, evident concept of how to explain it may be even not quite match the technical structure behind – but it will help people to do things they want to do.

For example take the “search function” in article lists (and other content elements). From a technical view it is a search function or a filter function, whatever term you like. From the view of users there are two things they want to do: Sometimes they want to search an article by its title or some kind of content. But often (when there are thousands of articles) they only want to see a subset, that is they want to filter the list for e.g. an author, to browse in that subset.
So I tried to get this “reading” of the function in its explanation. In consequence this will lead to the subtitle “Search and Filter” or like that.
If it’s only regarded as “Search function” some users will never discover that they can use the function to view a list of only their own articles.

And also I try to avoid “Äquivokationen” (missing the english term, should be ‘equivocations’, equal words meaning totally different things). They are numerous and a big problem for most users. Most of my time explaining software to people has to do with getting different things apart. So I look for ways to get terms different enough to be very clear from the beginning. Then of course there has to be a consistency in using them.
E.g. “page navigation” (in general ‘navigation of pages on the public-side’ – not necessarily between a numbered range of sub-pages – or ‘navigation between numbered sub-pages of an article list’ on the admin-side) and “link lists” (as a list of links on the public-side or the list of link-elements on the admin-side.)

You see, it’s a lot of things I try to do. I hope it will not annoy anyone.

Last edited by saccade (2009-01-11 13:13:38)

saccade · 2009-01-14 21:08:48

A new topic:
Reviewing “Write” again and again, I now want to make a proposal for naming the Write panel’s columns (only in TextBook for reference – not in Textpattern itself).

While I find the designation of its columns helpful and “stage” for itself nice, at the same time I think “utilities” “stage” and “settings” aren’t exactly matching and thus somewhat confusing. Also I have some difficulties to remember the triple and what is what.
E.g. “stage” for me is too obliged to presentation and motion software (Flash, Powerp.. and like that). A ‘stage’ for my imagination would require and lead to a lot of bells and whistles, but that may be only a personal approach.) Also it isn’t the whole “stage”. Something also happens in the left column, for example custom fields and image. Also if the powerful metaphor “stage” is used I think the whole thing/panel should stay within that picture/metaphor. Mixing pictures/metaphors is never intuitive. And here we have two metaphors at the same time: Theatre and Tool/Mechanism.
So I hope it is ok to look for another approach.

I tried to find out, which ideas (concepts, terms) most appropriate and intuitively reflect, what is actually offered in the columns.

Looking at the columns and what can be done there, we can say:

The mid-column is the main area, where article content will be edited. Main because it is not the only one (image and custom fields and keywords).

The left column offers additional options 1) how to edit (Textile), 2) what thing to edit (form and URL), and most important it offers additional content elements (image, custom fields, and keywords).
So I would sum up: It offers options for the editing of content.
Not least the column labels itself offer the term options.

In the right column we find things, that I think are best described as conditions of the content (an article) edited: It is “Live” or not, it belongs here or there, its comments are on or off and it has time conditions.

Main Edit Area sounds reasonable, explains itself and is comprehensible immediately.
“Options” and “Conditions” as terms in this couple I think play well together:
Options can be there or can be left out (like the things in the left column).
Conditions are always present/attached, it only depends on which conditions.

So I propose the following names for the three columns (written with Capitals to distinguish them from the normal use):

Options
Main Editing Area (or Main Edit Area?)
Conditions

Does that sound reasonable? Any comments?

Last edited by saccade (2009-01-14 21:15:21)

Destry · 2009-01-14 22:24:07

I agree it could be improved.

Options – OK, fits with the label that’s already there, but maybe not perfect. The right column has controls that provide options too (article state options, section and category options, date/time options…). Options might be too generic.

Main Editing Area – That’s better, but what about Article Editing Area, which specifically clarifies the nature of the editing area? (Or see below.)

Conditions – This one doesn’t click for me. It has connotations of ‘you can only do that if you do this.’ I actually think Settings is more logical here. When you have settings for something (article or anything else) you have a means for selecting a preferred set of values you want the thing to have, and which are often obligatory (even if just a default value). Further, it’s safe to say that everything in the left column are not settings at all, but “options.”

Another idea would be to not give the columns descriptive labels at all; instead, just call them columns by their location: Left Column, Middle Column, Right Column. (Ed. And apparently natural to do, as I just did it above without thinking about it.) :)

For example…

“In the left column of the Write panel you’ll find article markup options, form use options, custom fields (if desired), etc. The middle column is where you write and edit the primary pieces of the article (title, excerpt and body), and the right column provides you with the settings to publish your articles in relation to their topic context and your site’s architecture.”

I’m not suggesting to use that copy, but just showing that by referencing the column positions the descriptive copy is simple and perfectly clear.

The problem, however, is that Txp has labeled the left column as “Advanced Options” but not the others. I would say either that label should be removed, or the right column should be given a label too: Article Settings. The latter would be a positive usability change for that panel.

Last edited by Destry (2009-01-14 22:27:24)

Textpattern CMS

Textpattern CMS support forum

#13 2008-12-23 11:12:13

Re: [wiki] Textbook Terms and Terminology

#14 2009-01-08 17:15:14

Re: [wiki] Textbook Terms and Terminology

#15 2009-01-08 17:43:00

Re: [wiki] Textbook Terms and Terminology

#16 2009-01-08 21:42:36

Re: [wiki] Textbook Terms and Terminology

#17 2009-01-08 21:53:48

Re: [wiki] Textbook Terms and Terminology

#18 2009-01-08 23:31:48

Re: [wiki] Textbook Terms and Terminology

#19 2009-01-09 08:18:24

Re: [wiki] Textbook Terms and Terminology

#20 2009-01-09 08:32:10

Re: [wiki] Textbook Terms and Terminology

#21 2009-01-11 01:29:33

Re: [wiki] Textbook Terms and Terminology

#22 2009-01-11 12:45:48

Re: [wiki] Textbook Terms and Terminology

#23 2009-01-14 21:08:48

Re: [wiki] Textbook Terms and Terminology

#24 2009-01-14 22:24:07

Re: [wiki] Textbook Terms and Terminology

Board footer