Now my approach was the following. I have copied at the MySQL level, therefore in PHPmyAdmin the primary tables wp_1_posts, wp_1_postmeta to wp_2_posts and wp_2_postmeta. It is advisable before copying to switch on the hook  drop table, because the aim tables  already exists and cannot be overwritten. By this copy all posts get the same ID like in the original and therefore the relation  between post and attachment is preserved. Now the pictures can be described into the other language, because the picture descriptions (attachments) are given in copy, while the pictures themselves remain only at one place, uploading must not take place once again.

Moreover, it is advisable, the table which are responsible for the categories to copy also. With it the category allocation is already established, but of course not the translation. This should be carried out as a correction of the source language.

Although the articles have the same IDs like the original post – in different tables -, still no connection between them is established. Originally, I had thought to do this also  with an SQL operation, but this was a little bit difficult. The connections are established in wp_options as serialised entries. Therefore, I used the manual way given by MSLS. However, with an easy SQL operation I complement the non-translated articles with a suitable tip:

 update wp_2_posts set
`post_content` = CONCAT('<p class="notrans">Sorry, not yet translated!</p>',post_content);

The class information allows to format the statement  appropriately or to fade out it. Now the original text is available to me in the editor always for the translation. Being comfortable and because my English is still developable, I use an automatic translator (the Promptly translator), overwrite the sorry-text with the generated translation and correct it! This is absolutely necessary, even if your English is even worse than me, it is still better than the delivered one.

Some Plugins  can have their own data management as tables, these would also have to be copied  and then the contents be translated.

Now if necessary one must look for the widgets and upload the head pictures once again for the translated site.

A special difficulty still arises if one has used graphics as a blog title  which must / should be also translated. Here one has to offer both graphics  in header.php to  switche on them depending on the language surrounding. Here the code for the theme Twentyten.

In header.php the suitable place is to be overwritten as follows, of course with your own file names for the pictures.

    <<?php echo $heading_tag; ?> id="site-title">
        <span>
         <a href="<?php echo home_url( '/' ); ?>" title="<?php echo esc_attr( get_bloginfo( 'name', 'display' ) ); ?>" rel="home">
           <img src=<?php bloginfo( 'template_url' ); ?>/images/webkoch-en.png title="The Web Cook" alt="The Web Cook" />
           <img src=<?php bloginfo( 'template_url' ); ?>/images/webkoch-de.png title="Der Web Koch" alt="Der Web Koch" />
          </a>
         </span>
       </<?php echo $heading_tag; ?>>

Then in style.css one add these statements:

html body  img.schrift{display:none;}
*[lang |="en"] img.en {display:block;}
*[lang |="de"] img.de {display:block;}

Well, now I hope that I have forgotten nothing important. The danger insists of course that I have overlooked possibilities of MSLS and makes superfluous one or other work. It would be nice to get an adequate tip.

The first step is of course the transferring to WPMU or MU site or multisite or whatever you call it. If one follows the description, one should believe that everything is quite simple and perfect. This seems to be by no means in such a way, in any case, not with me. One follows the instructions http://codex.wordpress.org/Create_A_Network. I will not repeat this here, but the most important steps recall:

In wp-config.php  define (‘WP_ALLOW_MULTISITE’, true);  is inserted. Thereby one receives in the Dash/tool the additional option “Network …”. Now here one must go the Subdomain way, because the source site exists long since and one would not like to let go the original links into nothing.

After one has followed all instructions well, has used the additional statements in wp-config and has overwritten .htaccess as declared, has defined blogs.dir, one thinks, actually, now it would have to run again cheerfully. But this was not the case. I still had to carry out the following adaptations:

• the system asks for the root domain wp_1_posts,  wp_1_postmeta etc. this change was not carried out, the tables were called  wp_posts etc.  According to discussion in the forums, however, this might not be, however. I do not know, which mistake – if any– I have made. To me nothing else remained as all appropriate wp_ tables accordingly to rename.
• The original uploads-Directory has also not moved of course  by itself to blogs.dir / 1 / files/. However, the files were expected there from some Plugins. So I have shifted them accordingly. However, sometimes it is looked after the original links. Therefore, nothing else was left to me, than to put down the new absolute links in the Attachments also in phpMyAdmin accordingly.

As well as I write down this here, becomes clear to me that I must have messed up somewhere things. I think, it does not lie for the purposes of the inventors that one has to carry out these changes. But the way back is almost impossible , so that I see first no chance to repeat the whole process.

In the next post I will write about the use of this MU change for the multilingual facility.

(see. moreover also the discussion in https://www.xing.com/net/priabbe45x/wordpress/plugins-64292/plugin-fur-mehrsprachige-site-gesucht-37770664/p0)

WPML
- Very voluminously and need getting used to.
- annual costs (unique would be acceptable)
+ Workflow
+ multi-site capable, but doesn’t demand for WPMU.
+ SEO friendly also with single WP
+ separate data bank entries

qTranslate
- no workflow
- also not quite small
- “ruins” the data tables with Shortcodes for the languages
- handling with more than two oder three languages clumsy
- Translation of Widgettiteln probably realizable only with the shortcodes
- Deaktivierung practically not possibly
- considerable expenditure for SEO-urls, only with the help of additional plugins
+ short learning period

Xili
Here there are a few difficulties with the settings. Language switching in the frontend I wasn’t able to implement. Therefore, I could not test it thoroughly enough to deliver a judgment. It is similar to Polylang only not so simply, because it offers something more. It is worthwhile to investigate it deeper.

Polylang
- no workflow
- (still) not multisite able
- weak documentation
- + support only about wordpress.org, after 2 to 3 you get a very detailed reaction
- Difficulties with Widget from plugins, for every language you have to use an Extra-Widget
+ separate data bank entries
+ SEO friendly
+ easy service

Multisite Language Switcher
- workflow weak
- Difficulties if one wants to realise different translation projects in the same WPMU surroundings.
+ – only for WPMU
+ after short getting used to a supereasy service
+ SEO friendly
+ This system seems to be veery robust.

Multilingual Pressing of Frank Bueltge
Is not installable at the moment. According to description it might differ not so much from Multisite Language Switcher.

My recommendation:

1. For big sites with many languages and human translators you should use WPML
2. For 1-2-man-projects which one would not like to put on with WPMU t seems to me Polylang is most suitable
3. If one uses WPMU, one should take the Multisite Language Switcher.

http://www.qianqin.de/qtranslate/

As far as so well. And I can imagine that many are very satisfied with this Plugin. Nevertheless, I soon found the support forum  difficult to handle and to search in it seemed to be totally impossible for me. I have refused to set down in it my problems. However, then something happened that the mood totally went bad for me: fatally errors at all possible places which dealt nothing with WPML, e.g., with the picture high-level store or in the Dashboard-Homseite. Both without direct consequences, the pictures were, nevertheless, on top, the side worked. It was quickly clear that WPML with some Plugins was during the conflict, but this not in the usual manner: Switch off of the suspicious Plugins and it goes, Switch on again and it does not go any more. It was not so easy. Also switching off remained sometimes without effect or affected at other place fatally erratically. The desperation was limitless. I also was never sure whether my 2010-based theme  had caused this chaos, because it is not listed in the WPML-verified themes.

Nothing else was left to me, than to take up 30-days return option  and here I must say: this ran quick as a flash and quite correctly. Besides, one still assured me that 2010-theme is considered  and is verified.

I have grasped to qTranslate. However, here I have not found so much comfort: no workflow, no string translate, difficulties by the translation of widget titles. The clarity might be given to approx. 3 languages.

Who stands before the problem of his first multilingual site or is not comfortable with his current situation, should reach first after qTranslate.

School in Kachonga

Since some time I am involved in the association “Help to Africa – against AIDS and malaria  inc.” which provides straight assistance to a village in Uganda. My main activity is of course the production of a new website for the association. Now it is open and can be found under

http://kachonga.com

I am grateful for suggestions and criticism of course and even more for a click on the donation badges and left of a small donation.

Here a few more links to give Mr. Google some feed:

• http://kachonga.com/verein/
• http://kachonga.com/kachonga/projekte/
• http://kachonga.com/spenden/konten/

1. The picture mostly has a certain size which the loading times affect for the page
2. It is not evident that  a picture of limited dimension can fill out differently big browser windows, because a repetition of the picture forbids itself with this intend.

First is very briefly: with the today’s download times and computer speeds one should not use this as an argument against it. With 60 to 100 KB one can already provide enough pretentious pictures and one has these dimensions, in the end, mostly also with the other pictures.

But how one scales now a picture of fixed size on the respective browser size. In the net different attempts are introduced which can have advantages and disadvantages and  should not be discussed here. All attempts might have in common the following:

• The background picture is provided as an img-tag in the html code and not as a background image in the CSS
• To avoid an covering of the contents by the background picture, the correct representation order is produced by means of z-index in the CSS.

The picture is introduced before closing the body-tag enclosed in a div container:

<div id = "gallery-wrapper">
<img src = "path to bild/bild.jpg"> </div>

We call the Identifyer gallery-wrapper to indicate that here not only a fixed picture must stand, but also several pictures can be indicated after a certain algorithm, e.g., by chance or dependent on page.

The Skalierung of the picture and the representation levels for Content and picture are realised by means of CSS:

#gallery-wrapper img {
float:none;
margin:0;
min. height:100 %;
min. width:100 %;
width:auto;
}
#gallery-wrapper {
height:100 %;
left:0;
overflow:hidden;
position:fixed;
top:0;
width:100 %;}

With this code the picture scales, but it is not the background picturebut it covered the contents standing before it. If one assumes that also the whole contents standing before  are gathered into a div container (wrapped) and has e. g. the Identifyer wrapper, you can push upward the whole area by the CSS statement:

div#wrapper {z-index:2;}

Perhaps a higher value than 2 must be taken.

It should be noticed that with this technology, the picture shrinks only up to his original size. One should choose this size (exact width) according to the size of the contents area. With flexible layouts one should choose accordingly smaller dimensions of picture area what leads of course to worse quality with the enlargement. The kind of the elective pictures – do they stand such a deterioration with given motive? – plays also a certain role for the quality of the design.

WordPresser introduce the html code best of all in the footer file and the css code in style.css. Which div container the whole contents wrappt, depends on the Theme and must be determined accordingly, perhaps several containers “must be also pulled upwards”.

Who wants to indicate several pictures in WordPress by chance with the page change, the Plugin Random Image Selector can be used . A small change of this Plugins is necessary, so that it does not come into conflict with the above CSS instructions. For these changes you can aksed for me.

Then the main function of the Plugins is used in footer directly as follows:

<div class = "gallery-wrapper">
<? php
if (function_exists ('generateRandomImgTag'))
generateRandomImgTag ();
?>
</div>

A lot of fun while trying out!

Jigoshop  ist seit Mai 2011 ein neues, vielversprechendes  Shop-Plugin von WordPress. Um die deutschsprachige Community zu unterstützen und das in der Zwischenzeit kostenpflichtige Supportforum der Entwickler zu umgehen, haben wir ein Jigoshop Support Forum unter der Domain http://jigoshop.de eingerichtet. Für freuen uns auf Eure Beiträge, Hilfen und Fragen.

Die Moderatoren
Hans-Joachim Nolte und Dietrich Koch

Das Standard-Theme 2010 von WP 3.1 erfreut sich allgemeiner Beliebtheit und dürfte mittlerweile in zig-Abwandlungen zum Einsatz kommen. Mit wenigen Handgriffen kann man sich auch von der Beschränkung auf 940px Breite befreien. Dennoch bleibt die starre Breite für die Liebhaber des flexiblen Designs ein Handicap. Ich habe das Theme deshalb mit ein paar CSS-Statements zu einem flexiblen Theme erweitert, wobei ich allerdings nicht auf die gesamte Browserbreite gehe, sondern es auf eine maximale Breite von 1400px einschränke, die natürlich jederzeit geändert  oder ganz weggelassen werden kann. Die Flexibilität beschränke ich dabei nur auf den Content- und Kopfbereich, die Sidebar bleibt fest. Das Kopfbild wächst und schrumpft also mit.

Ob man nun den CSS-Code an das style.css anhängt oder ein Child-Theme aufbaut, bleibt jedem selbst überlassen. Im ersten Fall sollte man aber das Theme umbenennen, damit nicht beim nächsten WP-Update wieder alles hinüber ist. Hier der CSS-Code:


/* Korrekturen für flexibles 2010 im Content*/
#access .menu-header,
div.menu,#colophon,#branding,#main,#wrapper,#header,#masthead {
width: auto;}
#access .menu-header,div.menu,#colophon,#branding,#main,#wrapper,#header,#masthead {
max-width: 1400px;}
#branding img{
width:100%;
height:auto;
border:0;}
#imgtitle{
width:100%;
height:auto;}
#access{width:100%;}
/* Ende Flexibilisierung von 2010*/

Wer den Code nutzt, darf auch einen kurzen Kommentar hier abgeben. Alle anderen natürlich auch.

Ruft mich doch neulich mein Freund Bruno an, um mich zum Kaffee einzuladen, aber nicht nur dazu, sagt er, er habe ein Problem mit seiner Webseite, ob ich da vielleicht mal, ich sei doch Profi usw. Bis auf Bloggen und Bilder reinbringen habe er ja nicht viel Ahnung davon. Worum geht’s denn, frage ich ihn, als ich dann am nächsten Tag bei ihm eingetrudelt bin.

Na ja, das Design, eigentlich sei er ja nicht besonders pingelig, aber diese grüne Trennlinie zwischen den beiden Textspalten störe ihn doch sehr.

Ausgangssituation

Ein Designproblem, stöhne ich, da kann ich ja nur hoffen, dass das kein Tabellenlayout ist, das rühre ich mit Sicherheit nicht an. Ich werfe einen Blick auf den Quellcode – rechte Maustaste ist nicht geblockt – und sehe weit und breit kein table, td oder tr. Du scheinst Glück zu haben, da kannst du schon mal den Kaffe anwerfen und das Administratorkennwort raussuchen. Das will ich dir eigentlich noch nicht geben, sagt er, sonst machst du mir noch was kaputt, kannste nicht mal so gucken? Soviel zu „Profi“ und Freund. Meinetwegen, schau ich erst einmal so.

Weit und breit kein Firefox zu finden. Der Internet Explorer hat ja mittlerweile auch ein ganz passables Entwicklertool aber mit den von Firefox doch kein Vergleich, außerdem: die

Gewohnheit. Ich lade mir nun mit dem Internet Explorer – dazu muss er sich missbrauchen lassen – den Firefox, installiere ihn und hole mir gleich noch die Add-ons Firebug und Webdeveloper. Letzteren werde ich sicher nicht brauchen, aber man kann ja nie wissen.

Nun suche ich mir mit ein paar Klicks die relevanten Bereiche und – wie zu erwarten – wunderbar floatende div-Container.

Linker Bereich markiert

Nun, welcher der beiden hat nun diesen scheußlichen Rand? Der linke einen rechten oder der rechte einen linken? Gar keiner?

Was ist denn hier los? Aha, ich ahne,

Rechter Bereich markiert

welchen widerlichen Trick der Designer angewendet hat:

Einfach ein bisschen Margin zwischen den Containern gesetzt und damit den Untergrund des umfassenden Containers als Rand

benutzt. Das haben wir gleich. Wo ist denn nun margin-left oder margin-right. Ja, da gibt es margin-right, aber die Trennlinie ist rot und nicht grün wie der Hintergrund. Nun wird es ernst, der Kaffee wird wohl doch kalt werden. Keine ähnlich großen Container darunter oder darüber, die den Rand hätten liefern können. Ich ahne Schlimmes: irgendwo muss ein Hintergrundbild sein, das den Rand liefert. Solch ein sauberes Layout und CSS-Design und dann solch eine Trickserei. Ich kann es eigentlich kaum glauben.

Will da jemand die Spaltenbreiten ändern, muss er nachjustieren, will er die Farbe oder die Breite der Trennlinie ändern, muss er ein Grafikprogramm bemühen und das Bild natürlich wieder über ftp einbinden. Von einem flexiblen Layout, bei dem sich die Textbreiten dem Browserfenster anpassen, kann schon gar keine Rede sein. Welch ruchloses Tun und das bei diesem Design.

Bild für Trennlinie wird in unbekanntes Bild umbenannt

Aber tatsächlich, er hat es getan. Gibt es doch tatsächlich einen einschließenden Container mit einem positionierten Hintergrundbild von wenigen Pixeln, das sich beliebig oft vertikal wiederholt: die Trennlinie. Ich blende das Hintergrundbild im Firebug-Baum aus, indem ich es umbenenne und siehe da der Rand ist verschwunden. Nun aber ordentlich border setzen, die sich beliebig anpassen und auch blitzschnell ändern lassen. Ich gebe also dem linken Bereich einen rechten Rand mit einem dezenten Weißanstrich, alles temporär selbstverständlich, das Administratorvertrauen genieße ich ja immer noch nicht.

Linker Bereich erhält weißen rechten Rand

Dann scrolle ich ein bisschen nach unten und, oh Schreck, die Trennlinie hört mit dem rechten Text auf und links geht der Text ohne Trennlinie weiter.

Hässlich. Nichts einfacher als das. Gebe  ich also dem rechten Container einen linken Rand und schon läuft der Rand bis unten.

Rechter Bereich erhält linken Rand

Aber wie sieht denn das aus, oben ist er ja dicker als unten.

Oh Gott, ist ja klar, jeder Bereich will seinen eigenen Rand haben und drückt den anderen Bereich halt ein bisschen weg.

Nun fange ich an zu begreifen, warum mein Vorgänger diese Lösung gewählt hat, aber nein, ein Zurück kann es nicht geben, nachdem ich – wenn auch nur innerlich – mein Verdammungsurteil gesprochen habe. Kurz überlege ich noch, ob ich irgendeinen Trick ausfahre, um die Container gleich lang zu machen, dann brauch ich nur noch einen Rand, aber das verwerfe ich schnell wieder, nicht nur weil mir der Aufwand zu groß für dieses Miniproblem erscheint sondern vor allem, weil ich dieses Thema in einem meiner nächsten Artikel behandeln möchte. Bruno schleppt mir den lauwarmen Kaffee ran und kann sich ein „wird wohl nischt“ nicht verkneifen. „Verschwinde“, fauche ich und versuch, mich entspannt zurückzulegen. Da gibt es was, denke ich, und vermeide es, an mein Image zu denken sondern an das der Webseite. Da dämmert es langsam. Irgendwo habe ich von der „Saugkraft der Margins“, genauer der negativen Margins gelesen. Die Margin ist so etwas wie ein Niemandsland, du kannst es aber nur vor (positiv) oder nur hinter (negativ) der Grenze verwenden. Legst du es hinter die Grenze lässt es die Feinde über die Grenze springen und hinderst die Freunde sich zu verdrücken. Kam mir irgendwie bekannt vor. Also gebe ich erst einmal dem linken Container eine rechte negative Margin von der Breite meiner Grenze und siehe da, die Grenze ist überall gleich dick.

Linker Bereich erhält negative Margin von der Breite des Randes

Scheint so, als ob die eine Seite auf den Mauerbau verzichtet hat, sonst hätte es irgendwie

krachen müssen. Versuchsweise gebe ich der anderen Seite auch eine negative Margin. Wie sieht es nun aus? Darüber lasse ich Bruno grübeln, nachdem ich ihm das mit dem Niemandsland erläutert habe.

Um nun zu prüfen, ob die Trennlinie immer gleich lang ist, egal ob im linken oder im rechten Teil der längere Text steht, tausche ich nun die Texte aus. Natürlich gibt es mit der Trennlinie keine Probleme,

aber nun sehen wir eine andere Schwäche: die dunkelgraue Hintergrundfarbe des linken Bereiches sollte natürlich die gleiche Ausdehnung haben wie die Trennlinie. Bruno ist enttäuscht und ich muss noch einmal grübeln. Geht das mit CSS. Vielleicht mit dem gleichen fiesen Trick, der negativen Margin?

Ich dehne beide Bereiche mittels padding sehr weit nach unten aus, so dass mit Sicherheit jede Textlänge überschritten wird und nehme diese Ausdehnung mit Hilfe der negativen Margin gleicher Größe wieder zurück.

Gleichelange Bereiche mit Hilfe von Padding und negativer Margin

Um im obigen Bild zu bleiben: das Padding bildet einen inneren Schutzwall, der durch das Niemandsland negative Margin wieder aufgehoben wird. Und siehe da es klappt. Aber nur, weil wir dem Gesamtbereich schon mit overflow:hidden versehen haben.