StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>When you have been recommended to use gettext, it was actually an advise to use a <em>gettext-<strong>like</em></strong> translation system. Your current code is complex because of mnemonic text indicies. And the trouble you got into with the regular expressions for editing is caused by fiddling with variables in there. Let me propose some alternative code for transitional purposes.</p> <p>The beauty of gettext lies in its use of a non-obtrusive API. The function call <code>_()</code> is simple enough to be thoroughly used without adding much syntax or code bloat. It's preferrable to things like <code>getTextTrans('ABBR_TXT_ID')</code>. Using such mnemonic text ids is a widespread fallacy; because in practice there aren't frequent rewordings and <code>_("Raw english original text.")</code> serves the same purpose. However, since you already have mnemonic keys in place, keep them if it's too much to change. This is just a recommendation.</p> <p>Your real problem is the use of inline PHP expressions to build up the translation target strings. They are why the regular expressions for your translation editor became opaque. Therefore I'd highly recommend to use static strings and provide placeholders. The translation function should be tasked with handling it. (Don't worry about microoptimizing here!) - I would use <code>{$url_xy}</code> PHP/Smarty-style placeholders for example:</p> <pre><code>$txt['dp_who_forum'] = 'Viewing the forum index of <a href="{$scripturl}?action=forum">{$forum_name}</a>.'; </code></pre> <p>And a translation function that looks up a global placeholder table or params ($context) for replacing:</p> <pre><code>function __($text, $params=array()) { global $txt, $txt_placeholders; if (isset($txt[$text])) { $text = $txt[$text]; } if (strpos($text, '{$')) { $params = array_merge($params, $txt_placeholders); $text= preg_replace("/\{\$(\w+)\}/e", "$params['$1']", $text); } return $text; } </code></pre> <p>Optimizable. But this way you can use a static mnemonic->text or english->text set of translation arrays. <strong>You only use static strings in your text-translation-editor-form thingy. Those static strings are shown as-is, and your translators edit the english text, but not any of the <code>{$placeholders}</code>.</strong></p> <p>Hence your code for the translation feature won't need any of the complex regular expressions (in this case they are not useful) to match strings and inline PHP variables. In fact a much simpler <code>include()</code> and <code>var_export()</code> combination can now take its place:</p> <pre><code>function langSave($lang, $file) { $txt = array(); include($file); // assuming it contains a simple $txt = array(... foreach ($txt as $key=>$string) { $txt[$key] = $_REQUEST["txt$key"]; } file_put_contents($file, "<?php\n\$txt =".var_export($txt,1).';?>'); } </code></pre> <p>Filehandling and whatnot needs to be customized of course. But still this is a simpler approach.</p> <p>And it would further allow you to transition to one of the gettext variations as backends. Keep your custom wrapper function <code>__()</code> and use e.g. Zend_Translate as backend. This allows you to keep using your .php $txt=array() translation files (or I think so) or move to gettext-style .mo/.po files. The advantage of that being, that there is rich tool support in contrast to homebrew solutions.</p> <p>Anyway this is how you use the stuff in your main application:</p> <pre><code>print "<a href='...'>" . __("link_text") . "</a>"; print __("dp_forum_link"); // uses e.g. $txt_placeholder["scripturl"] print __("dp_param_link", array("scripturl"=>"http://override...")); </code></pre> <p>Moving from the short_txt keys to english->foreign text translation arrays would be advisable first, but in theory any of the backends from dvbs answer would be applicable. Now you already said that native gettext is not an option for you (for non-fastcgi PHP setups the memory resistance is a drawback). But PHPs native INTL features might be of help to you. In particular <a href="http://www.php.net/manual/en/class.messageformatter.php" rel="nofollow">http://www.php.net/manual/en/class.messageformatter.php</a> might be more useful than the simple-minded {$var} replacement wrapper I gave you. But I've never used it, and I think Zend_Translate is likely more useful. In particular can any of those backends give you charset independence. Personally I'd just stick to UTF-8, no matter what. But gettext .mo/.po files can each have their own custom charset for example.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload