Bug #53986 [Fbk-Opn]: Weird behavior upon reading .mo files

2011-02-14 Thread cristian dot datculescu at gmail dot com
Edit report at http://bugs.php.net/bug.php?id=53986edit=1

 ID: 53986
 User updated by:cristian dot datculescu at gmail dot com
 Reported by:cristian dot datculescu at gmail dot com
 Summary:Weird behavior upon reading .mo files
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:I18N and L10N related
 Operating System:   CentOS 5.2
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

?php

// set the locale

putenv(LANGUAGE=fr_FR);

setlocale(LC_ALL, fr_FR);

$domain_new = messages_1;

// bind the text domain

bindtextdomain($domain_new, dirname(__FILE__) . DIRECTORY_SEPARATOR .
locale);

// set the new domain

textdomain($domain_new);

$strlen = array();

// the sample text

echo gettext(Niste informatie de test!);

?



The .mo file contains only the Niste informatie de test! phrase
translated into version1. This script runned for the first time will
translate ok. Changing the name of the file to messages_2 and the
translation to version_2 [and updating the php as necessary], will
lead to keeping the old translation [although a new domain has been set]
or translating the text only about 50% [with a small deviation].


Previous Comments:

[2011-02-12 08:40:36] ka...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.




[2011-02-10 17:32:36] cristian dot datculescu at gmail dot com

Description:

When changing the .mo files, the changes are not taken into
consideration until reloading/restarting the webserver. The solution we
are using at the moment is to make symlinks for the modified .mo files
and version them (so basicly php ends up reading a default_5.mo file).
But we have run into a bug that it is for us very hard to track:
sometimes while changing the .mo files and updating the version, about
50% of the translation attempts fail, reverting to printing the original
text. It continues to do so until the webserver is reloaded/restarted. I
have managed to replicate the bug by doing this: create the sylink,
restart server, delete the symlink. In some of the cases the weird
behaviour will start to manifest. What is even weirder is that putting
back the symlinks does not help, the translation requests continuing to
be 50% failed.







-- 
Edit this bug report at http://bugs.php.net/bug.php?id=53986edit=1


[PHP-BUG] Bug #53986 [NEW]: Weird behavior upon reading .mo files

2011-02-10 Thread cristian dot datculescu at gmail dot com
From: 
Operating system: CentOS 5.2
PHP version:  Irrelevant
Package:  I18N and L10N related
Bug Type: Bug
Bug description:Weird behavior upon reading .mo files

Description:

When changing the .mo files, the changes are not taken into consideration
until reloading/restarting the webserver. The solution we are using at the
moment is to make symlinks for the modified .mo files and version them (so
basicly php ends up reading a default_5.mo file). But we have run into a
bug that it is for us very hard to track: sometimes while changing the .mo
files and updating the version, about 50% of the translation attempts fail,
reverting to printing the original text. It continues to do so until the
webserver is reloaded/restarted. I have managed to replicate the bug by
doing this: create the sylink, restart server, delete the symlink. In some
of the cases the weird behaviour will start to manifest. What is even
weirder is that putting back the symlinks does not help, the translation
requests continuing to be 50% failed.


-- 
Edit bug report at http://bugs.php.net/bug.php?id=53986edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53986r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53986r=trysnapshot53
Try a snapshot (trunk):  
http://bugs.php.net/fix.php?id=53986r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53986r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=53986r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53986r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=53986r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=53986r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=53986r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=53986r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=53986r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=53986r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=53986r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53986r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=53986r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53986r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=53986r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=53986r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=53986r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=53986r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=53986r=mysqlcfg