Comment 29 for bug 1152863

Fredrick,

Is there a reason that you did not simply create a string translation table and leverage the existing i18n code? For instance:

create table config.strings (
  purpose text primary key, -- store a use case label here
  string text not null -- store the en-US version here
);

insert into config.strings (type,string) values ('bool-op-and',' and ');
insert into config.i18n_core (fq_field,identity_value,translation,string) values ('es.string',' and ','fr-CA',' et ');

insert into config.strings (type,string) values ('bool-op-or',' or ');
insert into config.i18n_core (fq_field,identity_value,translation,string) values ('es.string',' or ','fr-CA',' ou ');

insert into config.strings (type,string) values ('bool-op-not',' not ');
insert into config.i18n_core (fq_field,identity_value,translation,string) values ('es.string',' not ','fr-CA',' pas ');

With an appropriately shaped set of seed data. Then, in the IDL:

    <class id="es" controller="open-ils.cstore" oils_obj:fieldmapper="config::strings" reporter:label="General translations">
        <fields oils_persist:primary="purpose">
            <field reporter:label="Purpose" name="purpose" reporter:datatype="text"/>
            <field reporter:label="Key String" name="string" reporter:datatype="text" oils_persist:i18n="true"/>
        </fields>
        <links/>
        <permacrud xmlns="http://open-ils.org/spec/opensrf/IDL/permacrud/v1">
            <actions>
                <create permission="ADMIN_STRINGS" global_required="true"/>
                <retrieve/>
                <update permission="ADMIN_STRINGS" global_required="true"/>
                <delete permission="ADMIN_STRINGS" global_required="true"/>
            </actions>
        </permacrud>
    </class>

And then, in metabib.pm, something like:

if ($args{_boolean} eq 'true') {
  for my $op ( @{ new_editor->search_config_strings( {purpose => {like => 'bool-op-%'}} ) } ) {
    (my $key = $op->purpose) =~ s/^bool-op-//;
    $parser->operator( $key => $op->string );
  }
}

And in EGCatLoader just go back to setting the _boolean arg to "true".

Then you're not introducing more stored procedures, and a trivally simple UI can be built on top of config.strings -- see basically any admin interface for an example. This would also leverage existing code that is well tested, and we'd get a place to store more general translations.

Sorry if that wasn't clear the other day when you asked privately in IRC for guidance ...

Regardless of the implementation maintenance cost of your current branch, though, the patch is lacking seed data and IDL entries for the new tables, as well as a way to control the translations.