Multi-lingual / func_entries

[Azundris]

Cursory search didn't answer this, so here goes:

s9y 1.3 (stock)

entries.tpl:
{if $entry.is_extended}
<div class="serendipity_entry_extended"><a id="extended"></a>{$entry.extended}</div>
{/if}

This works for me
- for "normal" entries (default language only)
- multi-lingual entries that do have an extended body for all languages (presumably having one for def-lang will suffice, haven't checked)

It doesn't work for
- default lang has no extended body, other language does have extended body

In the latter case, .is_extended is not set in functions_entries.inc.php as

if (isset($entry['exflag']) && $entry['exflag'] && ($extended || $preview)) {
$entry['is_extended'] = true;
}

fails, specifically the $entry['exflag'] part (isset, but to 0 as opposed to 1).

This seems to be a bug; presence of extended-body should be tested for the selected language (preferred), or a warning should be thrown if a multi-lingual entry is published that has an extended body for one or many languages, but not for the default language.

Besides, it would be kinda nice if we defaulted to the version the user chose in their browser's prefs, which seems to require

else {
$this->showlang=$serendipity['lang']; }

@ serendipity_event_multilingual.php:81 (but maybe I misunderstood the intention/implementation there?)

thanks/regards
-A-

[Azundris]

<div class="serendipity_multilingualInfo">Sprache wechseln: <a class="multilingual_de" href="/index.php?archives/116-German.html&serendipity[lang_selected]=de">German</a>, <a class="multilingual_default multilingual_English" href="/index.php?archives/116-Default.html&serendipity[lang_selected]=default">English</a></div>

"English" but "de", did I break that, or did you? Would also be nice if one could disable the lead-in ("Sprache wechseln") / have it wrapped in its own span, but since I'm fine with "flags only",

.serendipity_multilingualInfo { font-size: 0px; }
.multilingual_English:before { content:url(/uploads/en_UK.png)" "; }
.multilingual_de:before { content:url(/uploads/de_DE.png)" "; }
.multilingual_fr:before { content:url(/uploads/fr_FR.png)" "; }

works fine for my use case. ;)

[garvinhicking]

Hi!

That's not so easy because the Smarty template is not aware of any "other" extended bodies, because the DB only fetches the current language, not others.

There would need to be additional calls to the DB to circumvent that; but is that really required? If you want to read the extented body of a multilingual entry, wouldn't you first switch the language? And this in turn would reveal the extended link, right?

Besides, it would be kinda nice if we defaulted to the version the user chose in their browser's prefs, which seems to require

Have you tried enabling the s9y config option "Autodetect browser language"? Maybe this can already do the trick without patching?

"English" but "de", did I break that, or did you?

Ah, true. I'm not sure whether it would be good to fix this, as long-time users might have already used that string to apply custom CSS to it? Hrm. BC-break vs. unified classes...

Regards,
Garvin

[Azundris]

If you want to read the extented body of a multilingual entry, wouldn't you first switch the language? And this in turn would reveal the extended link, right?

Actually no; had that been the case, I wouldn't have seen it as much of a problem. But as it were, there was no way I could see the extended body (in the non-default language, if there was no extended body in the default language) at all. By which I mean, I found no way to display that text in the public part of the log; I could always call it up in the editor.

This is in 1.3; I upgraded (from 1.1.3, methinks) when someone complained about this behaviour, figuring it might be fixed in the current version. In other words, this has worked for me "two upgrades back", with whatever version I'd been using when I first wrote (and checked) the offending article.

I hot"fixed" it for the time being by giving the default language a token entry in the extended body. It's ugly, but it works for the time being.

A 30s test of change functions_entries to just test for isset(), but not for true fixed this for me ("extended" was shown for entries that had it, multi-lingual or not, and was not shown for one that didn't have it), but since I didn't really read much of the surrounding code, I have no idea what the original rationale for that was in the first place, id est, whether that would break anything else / create new corner cases that weren't covered in my "test."

Besides, it would be kinda nice if we defaulted to the version the user chose in their browser's prefs, which seems to require

Have you tried enabling the s9y config option "Autodetect browser language"?

That was and is enabled; it has always worked for the UI language, but I seem to recall it not working reliably for the actual entries.

"English" but "de", did I break that, or did you?

Ah, true. I'm not sure whether it would be good to fix this, as long-time users might have already used that string to apply custom CSS to it?

That seems willfully obtuse; my immediate reaction was to define it for *both* _en and _English to be on the safe side should it ever change, and I'm hardly the sharpest tool in the shed. :)

regards,
Azundris

[garvinhicking]

Hi!

When you open the single-article URL (the one with /archives/ID-bla.html) the extended body should always show up! Only in the entry overview you might not see that, but the final link should always take you there?

Toggling your check for exflag would mean that also non-extended entries would show up as extended ones.

Sorry that I cannot be of much more help; the multilingual entry plugin was always more of a proof-of-concept thing to me, that actual flesh-out was never taken on by anyone who uses this feature (i.e. not me ).

That seems willfully obtuse; my immediate reaction was to define it for *both* _en and _English to be on the safe side should it ever change, and I'm hardly the sharpest tool in the shed.

Hm, but using both would look awfully bloatish to me. But well, supposedly you're right that this would be better of.

Regards,
Garvin