To avoid breaking phrases we currently use placeholders like here:<div><br>(from koha-tmpl/intranet-tmpl/prog/en/includes/strings.inc)<div>var RENEWALS_REMAINING = _("%s of %s renewals remaining");</div><div><br></div><div>and then using like this:</div><div><br></div><div>(from koha-tmpl/intranet-tmpl/prog/en/js/checkouts.js)</div><div>RENEWALS_REMAINING.format( oObj.renewals_remaining, oObj.renewals_allowed )</div><div><br></div><div>so we can have most texts in one single place (language-wise) and then the JS somewhere else.</div><div><br></div><div>Regards</div><div>Tomás<br><div><br></div><div><br></div></div></div><br><div class="gmail_quote">El Fri Nov 21 2014 at 15:25:46, Jesse (<<a href="mailto:pianohacker@gmail.com">pianohacker@gmail.com</a>>) escribió:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've been working on Rancor, a professional MARC editor for Koha<br>
sponsored by ByWater and DGI, for the past year or so. As Rancor has a<br>
lot more client-side complexity than many other parts of the staff<br>
interface, I've run into some major frustrations. I have a proposed<br>
solution for them, and would like feedback from both developers and<br>
translators:<br>
<br>
Let's rewrite Koha in GWT!<br>
<br>
But seriously. The issues come down to translation. Making cleanly<br>
translatable JavaScript frontend code using Koha's current system<br>
requires a lot of finagling and ugly syntax, especially for any<br>
complicated string. There are two problems.<br>
<br>
Problem One:<br>
<br>
For example, displaying "You have checked out X books, Y of which are<br>
on hold" is frustrating to impossible for either the developer or<br>
translator:<br>
<br>
_("You have checked out ") + X + _(" books, ") + Y + _(" of which are on hold")<br>
<br>
is easy for a developer to write, but gives the poor translator three<br>
separate strings to translate. The commonly given solution is to<br>
rewrite this as:<br>
<br>
_("Books checked out: ") + X + _("Books on hold") + Y<br>
<br>
which works, but is a bit less elegant, and not always realistic. An<br>
informal best practice that has some precedent in the OPAC and<br>
Datatables is to use named placeholders in the string:<br>
<br>
_("You have checked out __X__ books, __Y__ of which are on<br>
hold").replace("__X__", X).replace("__Y__", Y)<br>
<br>
This is good, but currently has to be rewritten for every translated<br>
string. I'd like to propose a syntax like the following:<br>
<br>
_$("You have checked out $1 books, $2 of which are on hold", X, Y)<br>
<br>
or<br>
<br>
_$("You have checked out $X books, $Y of which are on hold", {X: X, Y: Y})<br>
<br>
with a slight preference for the former. Either approach allows<br>
translators to reorder substitutions as needed. The exact details of<br>
the syntax are up for debate, but something that can be implemented<br>
once, thrown into staff-global.js, and used everywhere is the goal.<br>
<br>
Either approach would be treated the same as:<br>
<br>
_("You have checked out $1 books, $2 of which are on hold")<br>
<br>
for the purposes of generating .po's and creating translated templates<br>
from existing .po's.<br>
<br>
Problem two:<br>
<br>
Currently, for JavaScript code to contain translated strings, it must<br>
be placed within a .tt or .inc. This is a historic limitation of the<br>
translation scripts<br>
(<a href="http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4503" target="_blank">http://bugs.koha-community.<u></u>org/bugzilla3/show_bug.cgi?id=<u></u>4503</a>). The<br>
stated reasons for not fixing it, besides the hairiness of the<br>
translation scripts, are that a) most JavaScript code has been moved<br>
to non-language specific directories and b) there are property-based<br>
translation systems available for JavaScript (see the<br>
datatables-strings.inc file for an example of how the latter works).<br>
<br>
Here are my reasons for disagreeing with these two points:<br>
<br>
a) Keeping most JavaScript code non-language-specific is a very<br>
laudable goal, both in terms of separation of concerns and<br>
deduplication of files in multi-language installs. I believe that the<br>
translation system should allow for translation of strings in .js<br>
files, however. Despite factoring out many modules and pieces of UI<br>
infrastructure using Require.JS, Rancor is currently sitting at ~1200<br>
lines of code that deal with showing error/informational messages to<br>
the user, all of which has to be in a .tt or .inc in the current<br>
system. This is untenable for any complex JS code.<br>
<br>
b) While this is more of a matter of taste, I do not like the<br>
properties-based translation system. For one thing, it punts the above<br>
problem to a solution like is used for datatables, with the<br>
translation strings in a .inc containing a single <script> and the<br>
rest of the code in a .js. Also, it introduces a layer of indirection<br>
that makes figuring out what is actually displayed to the user (and<br>
tracing where a given message came from) needlessly complicated.<br>
<br>
I believe that while the QA process should continue to encourage<br>
splitting out as much functionality as possible into<br>
non-language-specific JavaScript, _requiring_ it causes problems. I<br>
propose that the translation scripts be extended to process _() (and<br>
possibly _$()) directives in .js files in language-specific .../js/<br>
directories.<br>
<br>
(Note: this is not a "I think this is a fantastic idea that someone<br>
else should work on" proposal. I am willing and in fact eager to make<br>
these changes. But it would affect many people, so I want your<br>
thoughts first.)<br>
<br>
--<br>
Jesse Weaver<br>
______________________________<u></u>_________________<br>
Koha-devel mailing list<br>
<a href="mailto:Koha-devel@lists.koha-community.org" target="_blank">Koha-devel@lists.koha-<u></u>community.org</a><br>
<a href="http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel" target="_blank">http://lists.koha-community.<u></u>org/cgi-bin/mailman/listinfo/<u></u>koha-devel</a><br>
website : <a href="http://www.koha-community.org/" target="_blank">http://www.koha-community.org/</a><br>
git : <a href="http://git.koha-community.org/" target="_blank">http://git.koha-community.org/</a><br>
bugs : <a href="http://bugs.koha-community.org/" target="_blank">http://bugs.koha-community.<u></u>org/</a><br>
</blockquote></div>