You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@daffodil.apache.org by "Mike Beckerle (Jira)" <ji...@apache.org> on 2021/08/30 21:01:00 UTC

[jira] [Commented] (DAFFODIL-2543) Internationalization support

    [ https://issues.apache.org/jira/browse/DAFFODIL-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17406938#comment-17406938 ] 

Mike Beckerle commented on DAFFODIL-2543:
-----------------------------------------

I did some web searching. I did find this scalalingua thing: [https://github.com/makkarpov/scalingua/wiki/Using-with-Scala] (from a Russian guy)
 
It requires use of a different string interpolator than the standard ones. 
 
I did not find any credible i18n material that uses standard string interpolators. The things I found claiming string interpolation does not interfere or is compatible with i18n were naive as to the actual requirements to do i18n properly. 
  
So I think at this point using standard string interpolators is fine for logging and aborts, but not for SDE/SDW/PE/UE messaging. 
 
Ideally we should be using the f"..." interpolator, not s"..." because f"..." is type safe. 
 
This scalalingua thing makes heavy use of macros and so I worry about ongoing portability to new versions of Scala as they come out.  
 
But to the author's credit, it has the sbt plugin fully implemented to capture all the texts into the resource (gnu gettext .po or .pot) files. In that sense it is quite complete. I don't love the .po/.pot formats, but there is some tool chain around them. 
 
If we're going to advocate changing SDE/SDW and PE/UE messages to use string interpolation instead of SDE(string, args*) style, then I think we should be using a non-standard string interpolator that at least has the potential to support i18n some day without further code modification.  If we want to stub this with our own string interpolator that is exactly equivalent to the built-in f"...." interpolator for now, that would be ok with me. This would get us both type-safety from the f interpolator style and be i18n friendly for the future at the same time. 
 
 

> Internationalization support
> ----------------------------
>
>                 Key: DAFFODIL-2543
>                 URL: https://issues.apache.org/jira/browse/DAFFODIL-2543
>             Project: Daffodil
>          Issue Type: New Feature
>            Reporter: Steve Lawrence
>            Priority: Minor
>
> At some point, we may want to consider internationalization support.
> One approach here is to create a custom string interpolater, e.g.
> {code:scala}
> i"This message can be internationalized: ${withArguments}"
> {code}
> We likely want to create a macro for this, so that the raw message becomes the key to look up the internationalized string in the i18n database based on locale, and then the arguments are used to format the value found.
> Note that DAFFODIL-2510 changed all logging to use "s" string interpolation, and DAFFODIL-2542 suggests changing all of our diagnostics to use string interpolation as well. Once that is complete, switching to a new "i" interpolator becomes fairly straight forward.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)