Dit probleem is verholpen. Oorzaak wordt veroorzaakt doordat er een vertraging zat tussen de Core Engelstalige versie van WordPress 3.8.3. en de nl_NL versie.
Dank voor je antwoord Ruben.
Ik kan het niet meer controleren want versie 3.9 staat nu klaar.
Betekent dit dus eigenlijk dat een NL versie automatisch wordt geupdate met een EN versie?
thx
JP
@jpnl: Als men de nl_NL versie gebruikt moet natuurlijk ook de nl_NL versie van een . release beschikbaar worden gesteld. Dit is momenteel een handmatig proces wat overigens in de toekomst wordt verbeterd.
Mede gezien onze werkzaamheden voor 3.9. ontstaat er weleens wat vertraging.
@ruben:
Als men de nl_NL versie gebruikt moet natuurlijk ook de nl_NL versie van een . release beschikbaar worden gesteld.
Maar dat is precies het probleem. Mijn NL versie werd automatisch geupdate naar versie 3.8.3 zonder dat er een NL 3.8.3 was. Eén of twee dagen later (toen ik dus al op 3.8.3 zat) gaf WP aan dat er een NL 3.8.3 update was en die is niet automatisch geïnstalleerd.
Het duidt in mijn ogen op twee/drie mogelijke problemen:
1) Een NL 3.8.2 versie van WP wordt automatisch naar een niet NL versie 3.8.3 geupdate.
2) Als mijn NL versie al op 3.8.3 zit maar niet op de officiële NL versie, dan ziet WP dat wel, maar voert géén automatische update meer uit.
Voor wat betreft 1 kun je erover discussiëren of dat wel correct is. Voor een high prio fix is het denk ik wel gewenst, maar dan zouden de vertalingen daarna ideaal gezien apart aangeboden (en automatisch geupdate) moeten worden.
Hallo, ik heb deze melding weer op [Not resolved] gezet want het probleem heeft zich ook weer voor gedaan met de automatische update naar versie 3.9.1. Ik vind/denk dat WP nog eens goed naar het automatische update proces van de lokale taalvarianten moet kijken. (hoe) kan dat als bug of change request worden gemeld?
dank
JP
+1 (zie: http://nl.forums.wordpress.org/topic/update-beschikbaar-lijkt-taal-afhankelijk-bug?replies=2)
@ruben. Wat bedoel je precies met een ‘nl_NL versie van een . release’ ? .. WordPress in het nederlands gebruiken is toch een kwestie van WordPress variabele WPLANG omzetten naar nl_NL waardoor de juist vertalingsbestanden geraadpleegd worden. Dan zou je bij een update hooguit sommige termen (uit de nieuwe release) wellicht nog in het engels zien?
Of wordt er nog meer veranderd om tot de NL release te komen?
Dank en groet,
Gerard.
FYI: Dit is er, naast .mo en .po files uiteraard, aan bestanden veranderd na de nederlandstalige update (van 3.9.1) naar 3.9.1.
./wp-includes/version.php
35a36,37
>
> $wp_local_package = ‘nl_NL’;
Na een beetje Googelen zie ik dat er meer mensen hetzelfde probleem hebben en dat lijkt gerelateerd aan $wp_local_package.
Ik denk dat WP een dubbele versie check heeft
1) voor de WP core
2) voor de taalbestanden, maar op basis van wat?
Als bij een nieuwe release de nl_NL taalbestanden nog niet door het vertaalteam zijn bijgewerkt dan krijg je door de versiecheck van de core blijkbaar gewoon de nieuwe core maar met verouderde bestanden.
Vervolgens is er een release van de taalbestanden. WP ziet en meld dat wel maar doet dan geen automatische update meer. Het bijzondere is dat andere systemen die de versie controleren (zoals InfiniteWP en Wordfence) alléén de eerste controle doen.
@gerardjp, was bij jou na de eerste update de waarde van $wp_local_package ook al nl_NL of stond dat er pas na de tweede update in?
Ik zie twee mogelijke oplossingen maar heb geen idee hoe/waar je een dergelijke verzoek/probleem zou moeten neerleggen. Ik had gehoopt dat Ruben dat op zou pakken maar die reageert al een tijdje niet meer, helaas…
1) De update van lokale versie pas vrijgeven als ook de taalbestanden zijn bijgewerkt. Voordeel: je hebt maar 1 update. Nadeel: bij kritische bugfixes wil je daar niet op wachten.
2) De taalbestanden onafhankelijk van de core updaten, bijvoorbeeld zoals theme’s en plugins. Liefst ook automatisch.
Ik de automatische update optie maar even uitgezet, dan update ik gewoon handmatig een paar dagen na de release van een nieuwe versie.
Hi John-Pierre,
Thanx voor je uitgebreide feedback, blij dat er nog iemand begaan is met dit vraagstuk.
Wat bedoel je precies met mijn 1e en 2e update?
Ik kan het update scenario desgewenst nog een keer uitvoeren om te kijken wat er gebeurd.
V.w.b. de twee scenario’s die je schetst is er voor mij maar eentje en dat is 2. Ik heb een BV in WordPress Hosting en voorzie al mij klanten zeer tijdig van updates. De core updaten mag m.i. niet vertraagd worden door interface taal issues. Sterker nog, taal op de interface mag op generlei wijze invloed hebben op gedrag. Ik verwacht ook niet dat Mullenweg en de zijnen dit zo ingebouwd hebben in WordPress.
Wat ik zo gauw aan de taal bestanden heb kunnen zien zitten daar geen versies in opgeslagen. Nu is er een versie nummer van de database (tw: database revisie nummer) opgeslagen in de database. Zou er in de database ook een locale (language pack) revisie nummer bestaan aldaar?
Ik ben redelijk druk maar als dit probleem niet de aandacht krijgt die het verdient ga ik wat ruimte reserveren in de agenda voor nader onderzoek. Ik verkoop namelijk WordPress Hosting ‘inclusief updates’ en mijn nederlandse gebruikers zien ‘er is een update beschikbaar’ 🙂
NB: Ik ben zou vrij geweest om je even op te zoeken op linkedin.
@alle mede lezers: Alle input is welkom
Mvrgr,
Gerard.
Hoi Gerard,
Wat ik bedoelde met
– de 1e update: de automatische update van 3.9.1
– de 2e update: de 3.9.1 update die WP liet zien terwijl je al op 3.9.1 zat (door de nieuw NL taalbestanden).
Ik ben benieuwd of er nog een iemand met een reactie/oplossing komt.
thx
JP
Hi John-Pierre,
Dank voor je berichtje. Het gekke is dat in mijn installaties (de native uitvoering) de variable wp_local_package, behoudens in code, nergens voor komt of gezet wordt. Het enige wat ik doe is, na de wordpress installatie de taal bestanden plaatsen in de languages directory en in de wp-config.php file de WPLANG variabele op nl_NL zetten.
Overigens net met de hand “$wp_local_package = ‘nl_NL’;” geplaatst in version.php (zie boven) en dat had gelukkig geen invloed op de foutieve update melding. Dus theoretisch betekend dit dat er geen aanpassingen nodig zijn op de code base om van de melding af te komen.
Rest me toch die database dump analyseren 🙂
Mvrgr
Gerard.
