multilingual static page feature request

[mad-manne]

O.K. Here we go

I have at least accomplished the functional part of what I was trying to achieve ... and if I'm right also Carl Galloway way interested in this:

2. Could the static pages sidebar plugin be configured to show only pages from the specific language of the user, or if there aren't any pages then default to the serendipity default language (the one set in the configuration screen of admin).

Let's assume I'm planning to provide static pages in 3 differnet languages (english, german and french) and that I also want to use one static page as the blogs frontpage for each of these languages.
In addition I want to configure a default-language, that will "jump in", when a user has none of the 3 languages provided and this will be english.

On my demo-site I have generated different static pages for each of the mentioned languages and assigned them permalinks with an additional "virtual" subfolder containing the language-id. This "trick" with the language-ids is nothing necesarry for the function of it, but it looks better to me. The only thing that needs to be obeyed, is the fact, that the permalinks have to be different(see bottom of this thread)

I have done some code-changes to serendipity_plugin_staticpage.php and serendipity_event_staticpage.php, and as far as I can see, it works ....

You can try it over at my demo-site, where I have also added the "Choose Language"-sidebar-plugin, so that you are not forced to twiddle around with your browsers preferred language
If you choose any other language you should always see the list of english static pages.
The "imprint"-page is set to "all languages" and therefore it will always appear.

If anyone else is interested in this feature, then please let me know, so that I can find out who to contact to share my code. I will also have to code an admin-gui, because right now, the list of available languages and the default-language are hard-coded!



Another feature discussed earlier in this thread reads like this:

Example: You just link to pages/about.html. The code checks the language setting (be it a general setting or set by the language picker) and serves you the best possible language version. The same way it works with the startpage...

I am not sure, if this was just an idea or whether this is supposed to work in the way described ... BUT with my current installation I cannot confirm that this works.

Over at my demo-site you will also find a special subpage for each of my 3 languages called "multi_XXX-1", where XXX is the name of the language. All of the 3 pages have the same permalink. While the list of static-pages will display the correct name for each language, clicking the link will always bring me to the german page.

Cheers,
Manfred.

[mad-manne]

I will also have to code an admin-gui, because right now, the list of available languages and the default-language are hard-coded!

Hmmm ... somehow I couldn't keep my hands off this

I figured out I had to add 2 additional config-vars in the

Code: Select all

$propbag->add('configuration', array(

section of serendipity_event_staticpage.php and configure their parameters in

Code: Select all

function introspect_config_item($name, &$propbag)

The configuration-GUI of the plugin is extended as I expected, the config-table in the database has 2 new entries for the serendipity_event_staticpage-plugin and I can use these inside serendipity_event_staticpage.php like this:

Code: Select all

$lang_fallback = $this->get_config('lang_fallback');
$langs_available = explode('^', $this->get_config('langs_available'));

Here's a screenshot of the configuration-screen:
*Click for big version(919 x 485px, 60KB)*


... a problem
But now I seem to be stuck, because I also need to use these 2 vars inside of serendipity_plugin_staticpage.php and I don't know the correct way of doing this
I could surely add some piece of code and search inside the big $serendipity-array because I know that the variables are in there, but this looks like bad coding style ?!

Is there any "official" way how I can retrieve my 2 variables?

Looking forward to your feedback,
Manfred.

[garvinhicking]

Hi!

There are two ways to access the event plugins config values within a sidebar plugin:

1. The easy way: Just use a SQL query on the serendipity_config table and fetch the values wher ethe plugin name is like 'serendipity_event_staticpage:%'.

2. The nice but slow way: Instance the event plugin through the plugin API (load_plugin(...)), and then use this instance of the staticpage class to use ->get_config() calls.

I actually prefer solution 1.). The plugin serendipity_event_adduser / serendipity_plugin_adduser actually makes use of this, I believe.

HTH,
Garvin

[mad-manne]

1. The easy way: Just use a SQL query on the serendipity_config table and fetch the values wher ethe plugin name is like 'serendipity_event_staticpage:%'.
... / ...
I actually prefer solution 1.)

Hi Garvin,
thanks for your quick answer.
From my current tests, the variables are already inside the big $serendipity-array and they are referenced via their name-property from the config-table. If I can rely on them to be in that array, I don't have to invoke an sql-query?!

What do you think ?

Cheers,
Manfred.

[garvinhicking]

Hi!

Yeah, sure, you can also access the $serendipity-Array. But how would you get the unique ID from the staticpage plugin to use for the array-key? If you can figure that out, you can do it.

Regards,
Garvin

[mad-manne]

But how would you get the unique ID from the staticpage plugin to use for the array-key? If you can figure that out, you can do it.

This actually would have been my next question
Your answer sounds like there is no easy way of doing this?! So then I will actually have to go for that additional query.

Another question:
Would you consider to add my changes to this plugin(given they meet the coding standards)?
And if so, what would be the best practise to add my 4 new language-constants. I could provide them in english and german, but not in any other languages. Would I still add the untranslated Constants into all available language-files or not ?

Cheers,
Manfred.

[garvinhicking]

Hi!

Your answer sounds like there is no easy way of doing this?! So then I will actually have to go for that additional query.

I haven't really had the need to think about this yet, but there's no easy way that comes to my mind. You would need to iterate the whole $serendipity-array, which might not be the fastest way to deal with.

And of course I would like to add your code to the official plugin! If you can motivate some testers like YellowLED, Don Chambers or Carl to test your changes, that would be awesome. I myself don't use the multilingual plugin so I can give only very limited feedback - it would be great to have some testers that really work with the multilingual stuff.

And if so, what would be the best practise to add my 4 new language-constants. I could provide them in english and german, but not in any other languages. Would I still add the untranslated Constants into all available language-files or not ?

That's perfectly fine. The constants need to be added to the english file only; all translators use that file as a starting point to translate new strings.

Best regards,
Garvin

[mad-manne]

Hi Garvin,

You would need to iterate the whole $serendipity-array, which might not be the fastest way to deal with.

I have also spent a short thought on this, but as I would have to iterate the whole array with some sort of grepping on the keys, I'm sure this would cost more time than a simple sql-select.
I have in fact already added the necessary query and code into serendipity_plugin_staticpage.php that extracts the vars that I am looking for and puts them into a tiny array, that I can then use to do my task.

If you can motivate some testers like YellowLED, Don Chambers or Carl to test your changes, that would be awesome.

O.K. then ... I'll try my best

Another task to polish up my changes, would be a proper update-part because my changes add those 2 config-vars. I have already seen the

Code: Select all

function setupDB()

which looks like *the* place to add something. The way I understand it, I would just increase the db_built-count and add the necessary query to add my 2 vars in a new case-part?!

Cheers,
Manfred.

[garvinhicking]

Hi!

something. The way I understand it, I would just increase the db_built-count and add the necessary query to add my 2 vars in a new case-part?!

Exactly!

You're making quick progress, I like that

Regards,
Garvin

[mad-manne]

You're making quick progress, I like that

Thanks, but I am only just fiddling around at the surface ... there's so much more to learn and understand

One more question:

If you enhance functionality of the plugin, please add a file called "Change Log?" documenting changes.

The Link to "Change Log" seems to be unavailable, as you can see here ?!

What kind of changelog would you like to see? Is it rather a hand-written summary of the code-changes or a patch-file ??
If a patch-file is the right choice, is there any preferred format? My "diff-engine" WinMerge offers some different options(normal, context & unified), while the context & unified-format also offer the number of context-lines to look at (1,3,5 ...)

Cheers,
Manfred

[garvinhicking]

Hi!

If you enhance functionality of the plugin, please add a file called "Change Log?" documenting changes.

The Link to "Change Log" seems to be unavailable, as you can see here ?!

Ah, damn, that wiki system transforms "ChangeLog" to a wikilink. It should only be "ChangeLog" as the filename. There's no link for an example file like that.

Example ChangeLogs exist for example inside the staticpage plugin directory. Simply a new version string and the changes you pade. Hand-written, yes.

The patch that I need in the end would be a unified diff.

Regards,
Garvin

[mad-manne]

Hi Garvin,

Example ChangeLogs exist for example inside the staticpage plugin directory.

Oh my ... It was right there (almost) in front of my eyes. /me goes gets himself a new pair of glasses

The patch that I need in the end would be a unified diff.

Here's just a small example in unified-format with 3 context-lines. Is that the correct format for you?

Thanks again,
Manfred.

[garvinhicking]

Hi!

Yes, that's the right format.

Regards,
Garvin

[mad-manne]

It's me again ...

The way I understand it, I would just increase the db_built-count and add the necessary query to add my 2 vars in a new case-part?!

Apparently there's nothing I need to do, because I do not alter any TABLE-structure, and I have just tested an installation, where I started of with the unmodified plugin. Then I just overwrote the plugin with my new files, opened the plugins config-page and saved ... and voilá: the 2 new vars are in the config-table

Can you confirm, that this is supposed to happen ... the plugin-API seems to realize, that the two columns are not in the config-table and instead of doing an UPDATE it does an INSERT ??
Or was I just lucky or got confused with my various development-installations

Thanks for your patience,
Manfred.

[garvinhicking]

Hi!

If you simply use the $this->set_config and $this->get_config methods, then you do not need to worry about the DB. It is saved inside the serendipity_config DB table, which is normalized in a way that you can have generic "column" names.

Regards,
Garvin