[Savannah-dev] [bug #4247] include/i18n.php is not aware of the locale installation dir

[nobody]

=================== BUG #4247: LATEST MODIFICATIONS ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=4247&group_id=11

Changes by: Mathieu Roy <address@hidden>
Date: jeu 11.09.2003 à 16:33 (Europe/Paris)

------------------ Additional Follow-up Comments ----------------------------
1) Communicating in general.

1.1) savannah-dev is already in CC for any savannah bug tracking notification. 

1.2) It's very hard to communicate with someone not willing to declare his 
identity while it does not endanger his life at all.

2) About this bug in particular
2.1) If you have a broken system on which exists /usr/local/share/locale but on 
which /usr/local/share/locale is not in the TEXTDOMAIN, it's a problem of YOUR 
system.
I set by default the configure to pick /usr/share/locale because it's highly 
possible that /usr/locale/share/locale is not in TEXTDOMAIN under several knows 
systems.
But if someone want to use /usr/local/share/locale (for instance because he 
knows that his system is fine with that), there no reason to deliberately 
complicate this task to him.

2.2) Setting bindtextdomain manually is a way to configure in the software 
something that should be system-wide. It's probably more annoying than helpful. 
It's like configuring PHP binary path inside Savannah.

2.3) It's up to the people that maintain a software to make the decision 
whether a bug should be closed, opened, reopened. On some projects, only member 
of a project are able to add/modify bugs, because basically there are the 
person the most able to determine whether a problem a user encounter is really 
a bug in the software or just something that the user failed to handle for 
different reasons.
I enumerated 2 very valuables reasons to keep things as they are it's enough 
for me to close that bug and give a "WONT FIX" (if not an "INVALID") since 
there's no reason (apart: "on a broken system on which /usr/local/share/locale 
exists but is missing for textdomain, it does not work") to changes things 
right now.





=================== BUG #4247: FULL BUG SNAPSHOT ===================


Soumis par: aacosta                   Projet: Savannah                      
Signalé le: mer 09.07.2003 à 14:38
Category:  Web Interface              Severity:  1 - Enhancement            
Priority:  None                       Resolution:  Wont Fix                 
Assigned to:  yeupou                  Status:  Closed                       
Fixed Release:                        

Summary:  include/i18n.php is not aware of the locale installation dir

Original Submission:  The locale install directory should be stored during 
installation, for instance in a config file variable named sys_localeroot.



Something like  bindtextdomain ("savannah", $sys_localeroot); should then be 
added to include/i18n.php.



Otherwise internationalization wont work if the locale installation dir  isn't 
/usr/share/locale (/usr/local/share/localein my case)

Follow-up Comments
*******************

-------------------------------------------------------
Date: jeu 11.09.2003 à 16:33        By: yeupou
1) Communicating in general.

1.1) savannah-dev is already in CC for any savannah bug tracking notification. 

1.2) It's very hard to communicate with someone not willing to declare his 
identity while it does not endanger his life at all.

2) About this bug in particular
2.1) If you have a broken system on which exists /usr/local/share/locale but on 
which /usr/local/share/locale is not in the TEXTDOMAIN, it's a problem of YOUR 
system.
I set by default the configure to pick /usr/share/locale because it's highly 
possible that /usr/locale/share/locale is not in TEXTDOMAIN under several knows 
systems.
But if someone want to use /usr/local/share/locale (for instance because he 
knows that his system is fine with that), there no reason to deliberately 
complicate this task to him.

2.2) Setting bindtextdomain manually is a way to configure in the software 
something that should be system-wide. It's probably more annoying than helpful. 
It's like configuring PHP binary path inside Savannah.

2.3) It's up to the people that maintain a software to make the decision 
whether a bug should be closed, opened, reopened. On some projects, only member 
of a project are able to add/modify bugs, because basically there are the 
person the most able to determine whether a problem a user encounter is really 
a bug in the software or just something that the user failed to handle for 
different reasons.
I enumerated 2 very valuables reasons to keep things as they are it's enough 
for me to close that bug and give a "WONT FIX" (if not an "INVALID") since 
there's no reason (apart: "on a broken system on which /usr/local/share/locale 
exists but is missing for textdomain, it does not work") to changes things 
right now.



-------------------------------------------------------
Date: jeu 11.09.2003 à 15:25        By: None
At the date I reported the bug, "configure" script asked

about where I would like to install the .po files:

============================================================

Where should we install i18n files?

ex: /usr/share/locale

ex: /usr/local/share/locale

[/usr/share/locale]:

============================================================



Now, tell me, whats the point of asking that if include/i18n.php will only work 
if I answer  /usr/share/locale?



I answered the second of the _suggestions_ (/usr/local/share/locale), but 
include/i18n.php wasnt 

aware of that (using bindtexdomain as I suggested

would solve the problem).



This bug shouldn't be closed before deciding whether

removing that question from configure or include/i18n.php

is fixed.



-------------------------------------------------------
Date: mer 10.09.2003 à 12:03        By: yeupou
Hum, maybe you should set up your system to consider /usr/local/share/locale as 
a path of i18n, it would be easier than adding a bindtextdomain which may at a 
later time something that broke an installation.

Basically, a system set up to install things in /usr/local should have path 
according to that (for instance, if you shell $PATH environment value is not 
set for /usr/local/bin, it's pretty problematic to get binaries in 
/usr/local/bin).

So I'm not whether it's something we have to change in Savannah. In doubt, I 
close the report. But a report can be reopened if there are good reasons to see 
things differently.


La liste CC est vide


Il n'y a aucun fichier attaché actuellement


For detailed info, follow this link:
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=4247&group_id=11

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/