[sane-standard] sane standard proposals (4) "translation"

[Johannes Berg]

--=-88ivsr9w/L5a9tf9Yjpv
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Hi,

> Well, they are responsible for using a mecahnism to translate the
> messages. It's not the responsibility of the frontend authors to
> actually translate the options or to include the translations in their
> tar ball. That's why the .po files come with sane-backends.

Ok, I have misunderstood the standard then. In this case though, the
standard should not just propose to use gettext, but require it.

> That's one of the reasons for the discussions about how to transport
> the .mo files by using SANE API calls. These discussions should be
> somewhere in the sane-devel archive.

Apologies. I guess I missed that.

> Once the translations where splitted by backend. We (I guess it was
> mostly me) decided to merge all the translations to one file per
> language. One reason is that there are many options that are used by
> more than one backend. The second is that the chaos just gets to big.
> Imagine 50 backends with 10 languages ...

Yeah, good point.

> Another way would be:
>=20
> SANE_String
> sane_gettext (SANE_String_Const text_to_be_translated)
>=20
> I don't remember why we haven't discussed that one (maybe it's too
> slow?)

I think I like this better [but the prototype would need to be

SANE_String
sane_gettext (SANE_String_Const language, SANE_String_Const text)
]
because it frees the front-end author from the gettext dependency.

> We should also keep in mind the way the dll/meta backends work: The
> response to both functions comes from the dll backend if no
> SANE_Handle parameter is added.

Thats good too though, it avoids code duplication :)

johannes

--=-88ivsr9w/L5a9tf9Yjpv
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Comment: Johannes Berg (SIP Solutions)

iQIVAwUAQWrsEqVg1VMiehFYAQKzyA//ahLrnetiGek6DjnZ2ekbgZXQdQk7r9Ic
YROQYwqXjTXQHK94mpVmF16k0YbL6fzKCs2kjHbLByB1k3vOAjl1nAWNqg/NfVUj
sWYnPOUfFnKmJhMEhbV1Els4Fc+hVRoqZ81Li5GO6NGqIaIorJHNaNzjFKSlEtkB
3uhLAJ2niWW18b2gI6lXd/KQgRNW+Sy3Cw4NiwgHR186iznVcCnFol+AaTMnGKza
qg+Gg+kYd/6peVoUXuSbb1jgCKmThflZwCkf14AsN6Rug5BwDDD476dL1bg1l0h5
ySKBYCZDSNqybIzDumwYHbRqIOTOFzdtcu9YG47Ln5+TCEqnKn0G/V3qQD91jPin
XkqYAd16uLiANjUMrFpbJe1Rr0ax44d0KyMBH5hlPfoDMvcfRph0P9T0aEZfCtJk
9eVg6Imf9qdo1U34/R99EIqPR38RurGLydcLfKynp7CF6gUAtQqcLaR1s6aBApz+
1m6dluOZqu54tZZ6+Zs6cAHmdxRiQaJirmzUUm131IvM13LN/uZ3mScnzED8nbqm
+NZ2nh2zN3irUr3BfItstPlC/WA8bxQOTpnNg/9/uXQMIuk2bA0InZCiyIS7ll3Y
QFNZiLtlVcbrAAw7ZMqTXeTN138xun1N6gYf8jed+X0v86T4QBE0DbB1hGzGnbvg
Uaqn0Z6iHyI=
=tAcH
-----END PGP SIGNATURE-----

--=-88ivsr9w/L5a9tf9Yjpv--