Doc #63490 [Com]: Searching for _
| From: | narf at bofh dot bg | Date: | Thu, 31 Jan 2013 13:34:08 +0000 |
| Subject: | Doc #63490 [Com]: Searching for _ | ||
| References: | 1 | Groups: | php.doc.bugs |
| Request: | Send a blank email to doc-bugs+get-9500@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=63490&edit=1
ID: 63490
Comment by: narf at bofh dot bg
Reported by: php at jtrick dot net
Summary: Searching for _
Status: Assigned
Type: Documentation Problem
Package: Website problem
PHP Version: Irrelevant
Assigned To: danbrown
Block user comment: N
Private report: N
New Comment:
It doesn't directly go to gettext, but it seems to be the first suggestion now.
Previous Comments:
------------------------------------------------------------------------
[2012-12-05 23:27:53] danbrown@php.net
Just pushed two commits that should permanently resolve it, including a fix to
the manual-lookup.sqlite generator in systems. I'll leave it to generate on its
own tomorrow, like normal, and if it works we can close this one out.
------------------------------------------------------------------------
[2012-12-03 17:38:42] salathe@php.net
http://php.net/_ works because we have n array of URI aliases in the
error.php
script such that _ redirects to function.gettext
------------------------------------------------------------------------
[2012-12-03 12:56:21] bjori@php.net
Heh.
Looks like the fact it is an alias is just documented in an inline note.
I wonder why php.net/_ works then.
Documenting the alias properly by adding <refname>_</refname> to the refentry
should solve this bug then.
------------------------------------------------------------------------
[2012-12-03 11:48:34] salathe@php.net
"Since this is a real alias it is most definitely in the sqlite databaes so I've
no idea what is going on here" -- the _ alias is not in the sqlite database
(manual-lookup.sqlite) as there is no corresponding file in the docs (see
systems.git/gen-phpweb-sqlite-db.php which generates the sqlite database). At
least, it looks that way after a quick scan of the code.
For now, Adam's quick hack looks like the least invasive workaround.
------------------------------------------------------------------------
[2012-12-03 01:54:21] aharvey@php.net
Quite literally this, which doesn't fill me with great joy:
diff --git a/include/manual-lookup.inc b/include/manual-lookup.inc
index d12d7e1..f21dc18 100644
--- a/include/manual-lookup.inc
+++ b/include/manual-lookup.inc
@@ -83,6 +83,10 @@ function find_manual_page_slow($lang, $keyword)
// page shortcuts, so we avoid stat() calls on the server
function find_manual_page($lang, $keyword)
{
+ if ($keyword == '_') {
+ $keyword = 'function.gettext';
+ }
+
// If there is no sqlite support, or we are unable to
// open the database, fall back to normal search. Use
// open rather than popen to avoid any chance of confusion
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=63490
--
Edit this bug report at https://bugs.php.net/bug.php?id=63490&edit=1