COmanage Developers List

[Arlen Johnson <>]

Ok - I have a solution that follows on the third possibility which I believe to be simple and clean:

I plan to update the existing generic JS confirm dialog with an extra parameter: an array of strings to be used for token replacement.  If the array exists, we'll pass the strings to a function that will do the replacement.  Otherwise, the function will behave as it always has.  The original strings, with placeholders for replacement can live in the lang.php file in a form something like

'js.remove' => 'Are you sure you want to remove {1}?  It is included in the {2} collaboration...',

This would allow the sentences to be reformatted for localization (or just different wording), e.g.

'js.remove' => '{2} includes {1}: are you sure you wish to remove it?'

Arlen

On 8/21/15 7:11 PM, Arlen Johnson wrote:

_javascript_ widgets that do not require the inclusion of dynamic string parameters (which is most of them), we can use our normal lang.php library for the strings and the jtxt() function when appropriate.  We already do this 98% of the time.

So ticket CO-1130 is intended to address the i18n of that last 2% : _javascript_ widgets that require the inclusion of parametrized text.  E.g. "Are you sure you want to remove " + name + "?";  This is only two or three widgets.

There are two approaches we can take for managing the i18n for this:

1. Create the wrapping strings (prefix, suffix, etc) in the lang.php file and wrap things at the point of page generation in the php.  This is a bit weak in that we cannot ensure correct word order in localized sentence structures.
   
   
2. Create a new lang.js file in lib that provides localized strings and a _javascript_ function to process them just as we have with _txt().  Then, we can pass in the js parameters and have the localized sentence produced in the _javascript_ widget on the fly.

The first will certainly work.  The second will allow translators to adjust for word order, and should only require slightly more work - but it does mean that we are generating a new file for language strings.  A third possibility is to put the _javascript_ strings in lang.php as a block that gets pulled directly onto default.ctp in a <script> block ... which will allow us to keep all localizations in a single file ... if a little less clean.

Thoughts?

Arlen

On 8/21/15 6:29 PM, Arlen Johnson (JIRA) wrote:

     [ https://bugs.internet2.edu/jira/browse/CO-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on CO-1130 started by Arlen Johnson.

i18n for _javascript_ dialog box text
-----------------------------------

                Key: CO-1130
                URL: https://bugs.internet2.edu/jira/browse/CO-1130
            Project: COmanage
         Issue Type: Improvement
         Components: Registry
           Reporter: Arlen Johnson
           Assignee: Arlen Johnson
            Fix For: COmanage Registry 1.0.0 (Polished Polygon)


_javascript_ dialog boxes that are built in default.ctp should use i18n confirmation messages.  These can be passed to the function at the point of instantiation. 

--
This message was sent by Atlassian JIRA
(v6.2#6252)