Вам определенно нужны словарные таблицы: только с ними 2 разных пользователя приложения могут работать на разных языках одновременно.
Я рекомендую поместить некоторые из этих словарных таблиц в PHP, хотя это оказалось довольно ненавязчивым и производительным способом сделать это - например,
$translation=array('yes'=>'Ja','no'=>'Nein', ..)
//...
$row=mysql_fetch_row($qry);
//$row[1] has yes/no
$row[1]=$translation[$row[1]];
//...
$ translation может быть require_once() 'ed в зависимости от языковых предпочтений текущего пользователя, URL или любого другого
В основном вы торгуете некоторым ОЗУ для скорости и легкости.
UPDATE:
С Gior312, добавляющим информацию о поиске, вот мое решение для этого: иметь обратный перевод в таблице БД (вы даже можете использовать его для создания $ translation для скрипта):
CREATE TABLE translations (
id INT PRIMARY KEY AUTO_INCREMENT,
languageid INT NOT NULL,
enumword VARCHAR(m) NOT NULL,
langword VARCHAR(n) NOT NULL,
-- n and m to your needs
INDEX(languageid)
-- other indices to your needs
)
Теперь, когда поиск до сих пор был
$line=... //Maybe coming from $_POST['line'] via mysql_real_escape_string()
$sql="SELECT * FROM sometable WHERE somefield LIKE '%$line%'";
То, что вы сейчас делаете, это
$line=... //Maybe coming from $_POST['line'] via mysql_real_escape_string()
$sql="SELECT enumword FROM translations WHERE languageid=$currentlanguageid AND langword LIKE '%$line%'";
//fetch resulting enumwords into array $enumwords
$enumlist=explode("','",$enumwords);
//This assumes, that the field enumwords contains nothing, that needs to be escaped
$sql="SELECT * FROM sometable WHERE somefield IN ('$enumlist')";
Различия в трактовке прямого и обратного перевода по-разному:
- В коде, где вы будете отображать, будет гораздо больше строк, чем в том, где вы будете искать, поэтому незаметность прямого перевода важнее
- Прямое trnslation должно быть выполнено PER ROW (с объединением), обратное только PER QUERY, поэтому выполнение прямого перевода важнее, чем выполнение обратного перевода