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