[PHP] gettext & Wordpress

[Verwijderd]

Aangezien ik Wordpress met enige regelmaat voorbij zie schuiven, hoop ik dat misschien iemand een oplossing heeft op mijn volgende probleem:

Ik heb Wordpress 2.5.1 draaien, voor zover ik kan zien is PHP 5.2.4. geinstalleerd en is de gettext module geactiveerd op de server.

Wanneer ik een nl_NL.mo & nl_NL.po bestand in /wp-content/languages neerzet, wordt de text die vertaald zou moeten worden middels gettext niet vertaald. Enkel de stukken tekst van een post die ik tussen language tags gezet heb (middels een plugin), dit wordt door Wordpress als dynamische content gezien. Het gedeelte dat ik wil vertalen met gettext, wordt als statische tekst gezien.

In de wpconfig staat de locale op: ('WPLANG', 'nl_NL');

Voorbeeldje van wat er niet goed gaat:
In het bestand sidebar.php heb ik de volgende regel code staan:
<h2><?php _e('Language'); ?></h2>

In het .po bestand heb ik een vertaling gemaakt:
msgid "Language"
msgstr "Taal"

Dit zou dus moeten resulteren in het geval dat men de site in het NL bekijkt er dus het woord "Taal" staat op de plek waar in 't Engels "Lanaguage" staat. Helaas is dit nu dus niet het geval.
Nu blijft gewoon het Engels er staan.

Heeft iemand enig idee wat ik over het hoofd zie?

[NMe]

Verwijderd schreef op vrijdag 30 mei 2008 @ 13:33:
Dit zou dus moeten resulteren in het geval dat men de site in het NL bekijkt er dus het woord "Taal" staat op de plek waar in 't Engels "Lanaguage" staat. Helaas is dit nu dus niet het geval.

Wat doet het nu dan wél precies?

[Verwijderd]

Is de locale nl_NL wel geïnstalleerd op de server? En dan ook wel voor de juiste encoding?

[Verwijderd]

-NMe- schreef op vrijdag 30 mei 2008 @ 13:36:
[...]

Wat doet het nu dan wél precies?

Antwoord bijgevoegd in de TS.
Engels blijft staan...

Verwijderd schreef op vrijdag 30 mei 2008 @ 13:38:
Is de locale nl_NL wel geïnstalleerd op de server? En dan ook wel voor de juiste encoding?

Wat bedoel je precies en hoe kan ik dat controleren?
Uit phpinfo() haal ik alleen dit:
HTTP_ACCEPT_LANGUAGE nl-NL,en-US;q=0.5

[mcdronkz]

Verwijderd schreef op vrijdag 30 mei 2008 @ 13:50:
Uit phpinfo() haal ik alleen dit:
HTTP_ACCEPT_LANGUAGE nl-NL,en-US;q=0.5

Dat is de taal die de bezoeker in z'n browser heeft ingesteld (jij dus).

[Verwijderd]

Ok, maar daar ligt het dus niet aan.
Want als in in IE/FF de language perference aan pas van EN als primair naar NL als primair blijf ik de engelse static tekst zien.
Ook is het mogelijk om op de site zelf de taal te kiezen, maar dan veranderd enkel de dynamisch content, niet de static (die dus via gettext wordt uitgelezen).

[Verwijderd]

*schopje*

[uashy]

Wanneer ik een nl_NL.mo & nl_NL.po bestand in /wp-content/languages neerzet, wordt de text die vertaald zou moeten worden middels gettext niet vertaald.

Moet die niet in wp-includes/languages staan?

En voor de uiteindelijke werking hoeft in die directory ook alleen maar de .mo te staan, de .po heb je alleen nodig om de .mo aan te maken.

[ Voor 24% gewijzigd door uashy op 02-06-2008 18:13 ]

[Verwijderd]

Maakt geen verschil meer tegenwoordig. WP2.5 kijkt in beide mappen.
Uiteraard beide geprobeerd, werkte helaas niet.

[BCC]

Wordt de locale ook geset?

[uashy]

Ik neem aan dat je in de .po ook een regel hebt opgenomen die aangeeft in welk bestand en welke regel de string voorkomt?

code:

#: wp-comments-post.php:13
msgid "Sorry, comments are closed for this item."
msgstr "Vertaling"

[Verwijderd]

BCC schreef op maandag 02 juni 2008 @ 19:12:
Wordt de locale ook geset?

Wat bedoel je hier precies mee?

uashy schreef op maandag 02 juni 2008 @ 19:59:
Ik neem aan dat je in de .po ook een regel hebt opgenomen die aangeeft in welk bestand en welke regel de string voorkomt?

code:

#: wp-comments-post.php:13
msgid "Sorry, comments are closed for this item."
msgstr "Vertaling"

Nou niet die regel met 't # erin, wel de rest.
Moet dat wel dan?
Kan me niet herinneren dat ik dat in WP2.3 ooit heb aangegeven.

[uashy]

De voorbeelden in de Codex geven het wel aan. Heb zelf nooit gespeeld met gettext en vertalingen in Wordpress, maar als het nu niet werkt en je hebt die regel er niet bij staan kun je het allicht eens proberen om te zien of het dan wel werkt. Al was het maar om mogelijke oorzaken uit te sluiten.

[Verwijderd]

Voor zover mij bekend zorgt de # in code er voor dat 't niet wordt uitgelezen. Dus is dat enkel en alleen voor je eigen referentie. Niet voor de vertaling.
Wordpress leest gewoon nu het hele .po bestand niet uit, niet de standaard NL vertaling, en niet die met mijn aanpassingen.

[uashy]

In het geval van code heb je gelijk, maar in dit geval wordt duidelijk aangegeven in de Codex dat de # aangeeft voor welke regel van welk bestand de vertaling geldt.

Heb je toegang tot de logbestanden van de webserver of van php? Misschien dat je daar wat aanknopingspunten kunt vinden.

[Verwijderd]

Webserver wel, PHP geloof ik niet.
Kan ik wel eens vragen bij mijn hoster.
Al weet ik niet precies waar ik naar moet zoeken, daar ik daar niet echt veel verstand van heb.

Zit er wel aan te denken om eens een (VMware) test omgeving in elkaar te zetten met Apache erop + PHP & MySQL om te kijken of ik het probleem dan ook nog heb. Of 't aan de server ligt of aan mijn Wordpress install.
Echter zou ik niet weten hoe ik 't voor elkaar kan krijgen om zo'n test omgeving op te zetten.
Ben meer van de IIS en de MSSQL zeg maar.

[uashy]

Ik heb het even uitgetest en bij mij werkt het precies zoals ik al dacht, dus alleen als het per blokje de volgende opbouw heeft:

code:

#: wp-comments-post.php:13
msgid "Sorry, comments are closed for this item."
msgstr "Vertaling"

De regel met het # is dus wel nodig. Het maakt niet uit of het in wp-includes/languages staat of in wp-content/languages.

Dus probeer het eens uit en zet de regel met het # erbij. Het regelnummer moet daarbij wel overeenkomen met de regel in de php-code.

Edit: dit geld alleen voor de admin-interface. Voor plugins en themes gelden andere werkwijzes. Welke precies is wel terug te vinden in de Codex van Wordpress.

[ Voor 16% gewijzigd door uashy op 03-06-2008 20:29 ]

[Verwijderd]

't gaat bij mij dus juist om een vertaling uit een theme.

Blijkbaar kan dat niet met de standaard .mo files van Wordpress, die zijn bedoeld voor 't admin gedeelte.
Heb getest met de standaard nl_NL.mo file die daar voor bedoeld is, maar ook die wordt niet uitgelezen en dus 't admin gedeelte niet mee vertaald (niet dat ik dat noodzakelijk vind, maar puur als test om te kijken of de .mo file uberhaupt wordt uitgelezen). Blijkbaar zit er ergens iets mis in mijn installatie...?
En opnieuw beginnnen voel ik weinig voor, spoor liever de fout op en corrigeer deze.
Hopelijk kom ik er met jullie hulp achter.

Wat betreft themes vertalen:
http://boren.nu/archives/...izing-plugins-and-themes/

Blijkbaar moet ik een functie

load_theme_textdomain()

aanroepen, maar hoe en waar precies wordt mij niet duidelijk uit die tekst.

Toch denk ik dat eerst moet worden opgelost dat de .mo files uitgelezen worden, daarna pas de rest.

[ Voor 128% gewijzigd door Verwijderd op 03-06-2008 21:21 ]

[Verwijderd]

Nou na veel geklooi is het opgelost!

Kreeg een briljante tip dat het wel eens aan mijn gebruikte vertaal plugin zou kunnen liggen.
(Polyglot van Stryker).
Plugin uit gezet, en jawel hoor, de .MO file werd netjes uitgelezen in de backend.

Vervolgens een andere vertaal plugin geinstalleerd (QTranslate) en die werkte prima!
Wel nog wat schaaf werk te doen aan de layout nu, maar het belangrijkste is dat het nu weer werkt!