new table jos_languages

[akede]

Hi all,

I just saw that there is a new table jos_languages in the database on
1.6.

Actually this is now storing the same information in three places.
There was a discussion in the past how we store the language
information. I don't recall all the threads anymore, but the result
was that we agreed on storing all languages together with all other
extensions in the new jos_extensions table. There is a special type
called "language" that was defined for these languages.

I personally still think that this would be the best solution as a
language is an extension as we defined them. From my perspective there
is also no real need to have a specific table as well. The reason was
that we defined the relationship between content (e.g. articles) and
the language to be loose as it might be that someone deletes or
replaces a language and we don't want to have a constraint that
automatically deletes all articles related to a language.

I'm still in favor of having the language information only in the
language file and the jos_extensions table - may be we can clarify why
the new table is now implemented.

Thanks

Alex

[Christophe Demko]

The #__languages table has a different use: you can tag your content
with these languages.

The other language are for translating the 'words' of Joomla, not for
tagging contents.
e.g you can have only a english backend but your site can have
articles written in spanish, russian or even french. The #__languages
tables can be used for tagging these contents.

[Alex Kempkens]

Dear Christophe,

Yes the idea of tagging makes sense to me, but would it not be logical that if you provide content in a different language that you also have a frontend language installed for this language? If not you will have the standard text such as "search" or "written by" in English and the content in a different language.

From MPOV both belongs together and in this case it would be logical for me to tag the content with the reference (we decided on the ISO code earlier) to the extension table. If you like to select a language you like to tag your content with, then it makes sense to select one of those front-end languages installed (and I'm only talking about front-end language files, backend is always a different story).

Alex

[Christophe Demko]

You're right Alex. I did not think about these issues. So if we
install a frontend language, it should be an entry in the #__languages
table.

But, from a performance point of view, I think it's better to have
this table, instead of searching through folders.

[akede]

Dear Christophe,

Performance wise the table is perfect, absolutely agree. The
discussion I had with Sam was related the process of updates and
management of the language files as well. This was why we came up with
the idea of using the jos_extensions table for the language
information as well.

What is important for me is to not duplicate data that might get out
of synch to easy. In the past it was normal that you can install a new
front-end language just by uploading the language files to your server
directories. Now with 1.6 the installation will require most likely
that you add the information of the language to the jos_extensions
table as well in order to get it working correctly. If we now add an
another new table like jos_languages it will be needed to keep this
table in synch as well.

If we do this for adding more information like links to language flags
or specific configuration values that we link to the language I'm fine
with it. This is excatly what we do in the Joomfish project. But you
will understand that doing it just for a more easy access to the same
information I'm not certain if it is the right way to do it.

From my understanding we can store all required information for easy
access in the jos_extensions table. With some index on the type field
the access will be as simple and fast as having these information in a
separate table.

Just my toughts

Alex

[Andrew Eddie]

Hi Alex.

2009/11/23 Alex Kempkens <alex.k...@gmail.com>:

>
> Yes the idea of tagging makes sense to me, but would it not be logical that if you provide content in a different language that you also have a frontend language installed for this language?

No, it's not necessarily logical at all. Take my Art of Joomla site.
I regularly get people asking to do translations. I don't speak those
language but I would like to add them to my frontend to offer visitors
a choice. I don't want to have to go find a language pack for the
frontend and install it just so I can mark one article in another
language.

As Christophe says, the extensions table is for the installed language
packs, the languages table is for custom language markers. It will be
primed with all languages have TT's for (not all will be active
though). This gives the site owner complete choice on whether they
want to simply have tagged content in another language, or want to be
able to "switch" the site into a language mode, in which case the
language packs would also be used.

If you install a new language pack that is not listed in the languages
table, then the installer will add this to the list (doesn't yet). If
you remove that language pack, the language table reference will
remain.

Please note Alex, this is not a replacement for Joomfish but the core
should now provide common information that Joomfish relies on.
Language fields are to be added to all 'content' tables, modules and
menus.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

[Alex Kempkens]

Hi Andrew,

I'm not afraid this could be a replacement for Joomfish - not at all. If Joomla becomes more language aware you have my full support for this and I will even contribute to these efforts. The White paper I wrote is going exactly in this direction.

The reason why I pointed this out is because we had different discussions in the past and these changes have not been clear to me.

Ok to sum up the activities from here:
1. we add the language field to all tables (as specified in the White paper, those having an alias so far?)
2. we improve the language installer to keep this table in synch with the language extensions added
3. if you remove a front-end language pack - should the language be unpublished (at least as it is not removed)?

If decided to use such a table as reference I would suggest we add some more columns which allow additional information or reference for a language. Something like a params field.

Within Joomfish we do have two different status fields for a language. The first one is similar to the published column and allows to use the language in general (specially within the backend) the second one is called "active" and indicates that a user can also select this language in the front-end. There are cases in which a language should only be available to translators (e.g. authors or publishers) but not yet to the general public. May be it is a good idea to allow this kind of differentiation as well?

Cheers

Alex

[Alex Kempkens]

Christophe,

are you using a branch on joomlacode to work on this?

Alex

[Andrew Eddie]

Hi Alex.

The language table in the default install will be primed with all our
support languages. The published field will have 4 values.

1 Published - active on the frontend.
0 Unpublished - not active on the frontend but able to be set by
anyone with edit rights to be able to prepare content for that
language.
-1 Archived/Disabled - not shown in any lists, but available to turn
on if you want it.
-2 Trashed.

I think that should cover all bases with a bit of fine tuning.

I didn't really see the need for params but only because I couldn't
think of a good use-case. I think we can massage the ACL to cover the
other case you cited. I would probably wait until I have the whole
system working in a draft mode and then we can look at what's working,
what isn't, what need improving, etc.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

2009/11/24 Alex Kempkens <alex.k...@gmail.com>:

[Ian MacLennan]

On Mon, Nov 23, 2009 at 2:53 PM, akede <alex.k...@gmail.com> wrote:

What is important for me is to not duplicate data that might get out
of synch to easy. In the past it was normal that you can install a new
front-end language just by uploading the language files to your server
directories. Now with 1.6 the installation will require most likely
that you add the information of the language to the jos_extensions
table as well in order to get it working correctly. If we now add an
another new table like jos_languages it will be needed to keep this
table in synch as well.

Just to clarify the discussion - are you implying that we should try and maintain the ability to install languages by just uploading files to the server?  If that is what you are implying, I disagree with that being a criteria.  I don't think it is unreasonable to have to manage languages via the extension manager.

Ian

 

[Alex Kempkens]

Just to clarify the discussion - are you implying that we should try and maintain the ability to install languages by just uploading files to the server?  If that is what you are implying, I disagree with that being a criteria.  I don't think it is unreasonable to have to manage languages via the extension manager.

Ian

Hi Ian,

No I'm not implying this - I'm absolutely for removing this way of handling language files. I was already advocating to remove it in 1.5 long time ago. Languages should be treated as any other extensions IMHO.

Alex

[Andrew Eddie]

Alex, unless I misunderstand you, you are confusing the language
"extension" with language metadata (this is, being able to specify the
language of content). They are different things.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer




2009/11/24 Alex Kempkens <alex.k...@gmail.com>:
>>>

[Christophe Demko]

Alex,

Do you expect that I had to work on this specific task? In this case,
I can't. I have for the moment too much work (and I don't have a
branch on joomlacode).

I participate to the

Christophe

[Alex Kempkens]

Dear Christophe,

I did not expected - I just was wondering. Your feedback and suggestions are highly welcome and I would like to invite you to share more thoughts with JM and me.

Cheers

Alex

[Alex Kempkens]

Hi Andrew,

I summarized the feedback and clarification in our Wiki http://docs.joomla.org/Language_Metadata .
Could you please have a look on the page and help me to make sure there is no more confusion between those terms.

Thanks

Alex