Symphony.

Hello.

I need to store NxN-tables, where N can grow. Example of such data is as follows, but the use of it could be IMHO very general:

<?xml version="1.0" encoding="UTF-8" ?>

<language code="eng">
    <name code="eng">English</name>
    <name code="deu">Englisch</name>
    <name code="ces">angli?tina</name>
</language>

<language code="deu">
    <name code="eng">Gernam</name>
    <name code="deu">Deutsch</name>
    <name code="ces">n?m?ina</name>
</language>

<language code="ces">
    <name code="eng">Czech</name>
    <name code="deu">Tschechisch</name>
    <name code="ces">?eština</name>
</language>

Is there a way/extension to cope with such data in Symphony?

Also an extension to cope with N-list data is needed:

<month seq="1">
    <language code="eng">January</language>
    <language code="deu">Januar</language>
    <language code="ces">leden</language>
</month>

What I need it for is fully multilingual websites where everything is translated to the target language. I got, for instance, section called “Articles” and now I need to create translations of the word “Articles” for every single language the page will finally use.

The two conceptions, NxN-table and N-list, would solve both problems very elegantly.

Are there some extensions for it? I do not see any extension to cope with such sort of (general) problems described.

Relational databases can’t handle matrices themselves but you can create a NxN-matrix-like schema by creating two tables: Language-Acronyms and Language-Names.

Language-Acronyms takes a string, like “eng”, “deu” or “ces”.

Language-Names takes a string, like “English” and two select box links (SBL), both pointing two Language-Acronyms. One SBL is named “Name For” the other one “In Language”.

That way you can create data that basically says: “German” is the name for “deu” in English.

Same goes for your N-list, except the SBLs won’t point to the same section.

It will work (although the creation of the data is not very user-friendly). Thanks, it’s smart!

I wonder if the Meta Keys or Subsection Manager extensions might be used in a creative way here. A Language section (name and acronym) could have a child field (Meta Keys or Subsection Manager perhaps) that allows you to add N-number of translated words.

Or perhaps you begin with a master “Words” section that stores the words in your master default language (e.g. English) and use a Subsection Manager to add translations of that word. The section that it uses as the child field, “Translated Words” would have a dropdown for language, and a text input for the translated word.

Do you need to display the values in different languages at the same time? If not, why not just use the Multilingual Field which can store a value in several languages at once. This field is automatically filtered by the current language (from Language Redirect) in data sources, so your views don’t need to think about which language to output.

With the Multilingual Field extension you edit the same value in multiple languages at once (through a tabbed interface).

@all: The problem is solved.

Just to describe my final solution, in case somebody liked it too -

I maintain two types of data - the “keys” and the “data”. The language keys section is called “Language keys” and has the following entry fields:

Language keys {
  Key       (Text Input Field),
  Direction (Select Box Field for "ltr" and "rtl" values)
}

Some example “Language keys” entries:

{"eng", ltr}
{"ces", ltr}
{"deu", ltr}

Data section for language keys is called “Languages” and has the following entry fields:

Languages {
  For   (Select Box Link Field for "Language keys -> Key")
  In    (Select Box Link Field got "Language keys -> Key")
  Value (Text Input Field)
}

There are some entries for the “Languages”:

{eng, eng, "English"}
{eng, deu, "Englisch"}
{eng, ces, "anglictina"}
{deu, eng, "German"}
{deu, deu, "Deutsch"}
{deu, ces, "nemcina"}
{ces, eng, "Czech"}
{ces, deu, "Tschechisch"}
{ces, ces, "cestina"}

So, that’s the NxN problem solved and very usable too, I guess. The only thing that’s bad that I can no sort by every column in the section overview except the columns containing some text field. This is bad and I simply do no see any technical reason why Symphony does not know to sort by any column it shows in a section.

Now, having this “language-matrix”, I just create every other data section similarly, for instance:

Place keys {
  Key    (Text Input Field)
  Parent (Select Box Link Field for the "Place keys / Key")
}

And some “data” section “Places” too:

Places {
  For  (Select Box Link Field for the "Place keys / Key")
  In   (Select Box Link Field for the "Language keys / Key")
  Name (Text Input Field for place "name")
  ...
  ...
  ...
}

In other words, if there was some “Geo” information needed that does not need translation, it will go to the “Places Keys” section. Everything translatable goes to the “data” section “Places”.

This way, I can maintain multilingual data of everything I need (some messages, errors, articles, user given and family names, X-SAMPA data, even names of the sections from XML source etc). Great!

It would be really nice if somebody generalized good extension from this conception, especially to enter and maintain the data more easily. (What do you think, Nick?) As number of used languages grows, and without the ability to order the view of the data somehow sensibly, it’s less and less easy to maintain. That’s the remaining problem of this conception…

I’ll just chip in and say you can’t sort on a Select Box Link for a few reasons. Because the SBL field links by ID the sort would need to join the linked field table, which would bs technically possible. I suppose it hasn’t been implemented yet because nobody has really had the need yet? The concept breaks down when the SBL field allows multiple selections; it is no longer sortable. Perhaps we could allow sorting when the field is in one-to-one mode.

@nickdunn:

Hello Nick.

Thank you for your reply.

I think one sort of extension would help. If there was an option “Group by” in a section editor to provide grouping section entries in the section overview by a field of choice. That would be nice and generally very useful in case you maintain large datasets in some section where one entry field has the same values for many of the entries. In my case, I would group by the “For” fields for the “data” sections. For the “Languages” the listing in the “Content / Languages” would look like:

eng group:

eng     eng     English
eng     ces     anglictina
eng     deu     German

ces group:

ces     eng     Czech
ces     ces     cestina
ces     deu     Tschechisch

deu group:

...
etc.
...

instead of the mixed mash I must work with now. I will really need to add some 10+ more languages soon. Uff, that would be very painful to maintain (you have to do side remarks on paper or in some file to not forget anything). Although your “Duplicate entry” extension really helps with inserting new entries, the overview is useless and scary…

Similarly for section “Articles” and all other “translated” sections I maintain.

The extension should also switch off the default pagination of the entries or at least let the user choose better pagination value. I lack this feature in general, I must say. The default number is too low. Why is it so low?

Off-topic:

Quite similar problem, but concerning DS, with pagination exists in general in 2.1.2. Therefor I switched to 2.2beta, because of the fact that I can switch off the pagination feature in DS.

Similarly I still do not know how to switch off the “Limit to the most recent entries” in the “Select Box Link Field” I use extensively. I just put 99999… numbers there which is not ideal at all. I would suggest “-1” as “infinity” there or some check box to enable/disable it rather then to use such ugly numerical tricks…