Handling of entry language

[Zugschlus]

Hi,

I am blogging both in German and English. One entry might be in German, the next one in English.

Currently, the themes default to hard-coding "auto", which makes the browser think all entries are written in the browser's preferred language. This is very often the wrong assumption.

There should be an entry-related setting giving the language of the entire article, with a default to be set in the site configuration. This setting should result in the appropriate language being declared in the CSS delivered to the client. Overview pages could also probably set the language for the respective excerpt that is rendered into the page. I am sure that a language property can be tacked to a div container in the rendered page.

Gold plating would be a possibility to declare parts of an entry to be in a different language than the rest of the entry to avoid the browsers to do absurd hypenation.

Thank you very much for considering this improvement suggestion.

Greetings Marc

[stephanbrunker]

This is an inherent weak point in the inner functioning of s9y in terms of multi-lingual. You have in the site configuration one language defined as default language. The multilingual plugin allows you to create translations to that default entry, but not the other way round as an entry ID has to exist to create an translation. So if your blog default language is German, an English article can only exist (with the multilingual plugin) as an translation of a German one.

Theoretically, it would be possible to re-create the multilingual functionality in a way you suggested above with a free selection of the article ID and language, but there is a problem. The current developers in charge shy away from all intrusions into the core and that would be a really big one because it is essentially a total recreation of the article structure in the database, away from one-dimensional ID based (with translations patched on top of that) to two-dimensional ID and lang based which would also make the multilingual functionality part of the core (which I think it is anyway). There is also a lack of interest in these features, unfortunately. The resulting effect is that I wrote several features (for example: email subscribers in their chosen language) which did need adaption in the core and just need some debugging to be merged (which I cannot do because of different platforms). But there is nobody who wants to participate because of the said reasons, so my work ist stuck in-between and more or less in vain seen from the current situation.

So even if I think your suggestion is a good one (better than try to create a honky workaround for an article which doesn't exist in the default language which means patching the translation on nothing and identify and skip that nothing), it lacks support from other developers and because of the massive impact into the core and re-organization of the existing tables doesn't have a chance to be merged into s9y. I could and would make this possible (and i have a fairly good idea how), but not without participation from others and thus the guarantee that the feature would make it into the next release because then I am not the only one with a major time investment which is a great motivator. But when these conditions are met, I would contribute my part.