On 7/25/07, Mike Rylander <[EMAIL PROTECTED]> wrote:
On 7/25/07, Bill Erickson <[EMAIL PROTECTED]> wrote: > > > On 7/25/07, Mike Rylander <[EMAIL PROTECTED]> wrote: > > On 7/25/07, Bill Erickson <[EMAIL PROTECTED]> wrote: > > > > > > This is obviously on the side of "more work" ;) > > > > > > > heh ... I'll say so. One thing this drops, though, is the command > > renaming which would actually give us i18n for free. > > I'm definitely missing something. What's being i18n-ized in srfsh? Nothing directly, but if we allow the config file to define the spelling of the commands, then everything (basically). Imagine <extension command="login" object="foo.so" func="login_func"/> for English, but replace it with <extension command="connexion" object="foo.so" func="login_func"/> for French.
I think of srfsh as a progromatic interface as much as a human-interaction interface. Providing translations for script commands feels odd to me. If we change "request" to "demande" for French (or "login" to "connexion"), how do we handle the existing srfsh scripts that call those commands explicity? We force the external scripts to pass en-US as the srfsh locale?
> That reminds me, I guess srfsh will need an additional environment variable > for setting the OpenSRF locale once that exists... > There are plenty of locale-ish env variables already. See $ locale -v
Good point.
> I'm probably > > missing something, but what is all that infrastructure buying us that > > a simple config file controlled hash not? > > I'll wait on the patch to make sure I'm understanding the proposal... > OK ... I think we're imagining the same functionality, I'm just seeing a simpler (dumbed-down?) implementation.
Yeah, I think so. -bill
