COmanage Developers List

[Benn Oshrin <>]

If I understand what you're proposing this seems pretty reasonable to me.

On 8/22/15 2:52 PM, Arlen Johnson wrote:
> 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)
>>
>