[katello-devel] Fwd: [Pulp-list] i18n input

[James Bowes]

On Wed, Oct 03, 2012 at 08:33:50AM -0400, Jay Dobies wrote:
> On 10/03/2012 08:21 AM, James Bowes wrote:
> >On Tue, Oct 02, 2012 at 04:43:07PM -0400, Bryan Kearney wrote:
> >>Comments?
> >
> >rpm enforces no such restriction, so you can look forward to enjoying
> >changelog entries encoded in Big5 and other esoteric formats. You can
> >probably borrow some code from yum for trying to convert those, and
> >falling back to a missing char symbol or '?' if not.
> >
> >Is it safe to assume pulp will gain i18n/l10n shortly, too?
> 
> Depends on what you mean.
> 
> This conversation has been around handling data, but from the server

It has, but the data it's about is data from non english speaking users.
You can't support them properly without doing i18n/l10n right, too.

> standpoint there are very few places we're returning anything
> user-facing. So from the perspective of a REST API caller they are
> largely just getting data back and an exception structure to
> indicate what went wrong, they can do as they wish.
> 

There's a few strings in the server code marked for i18n. Some that get
logged are, for example, yet others are not.

> From the CLI, support is mostly there as well. There are probably
> places we haven't run through gettext, but those are minimal at this
> point. We haven't started pulling together translations yet though.
> 

You should start :) I can see a number of places where the code is doing
the wrong thing with gettext.
platform/src/pulp/client/extensions/exceptions.py line 108 is a good
example. That string won't be included in your po files.

i18n is messy, hard, and invasive. Even if you don't have localizations,
you can still make a dummy locale with some nonsense strings (I tend to
use en_CA), to verify your strings are extracted properly, and replaced
properly, too. Best to start as soon as possible, and get the pain over
with.

> >>
> >>-- bk
> >>
> >>
> >>
> >>-------- Original Message --------
> >>Subject: [Pulp-list] i18n input
> >>Date: Tue, 2 Oct 2012 14:40:18 -0600
> >>From: Jason Connor <jconnor at redhat.com>
> >>To: pulp-list at redhat.com <pulp-list at redhat.com>
> >>
> >>Hi All,
> >>
> >>Lately we've been struggling with a rash of bugs related to i18n
> >>input in Pulp. Python 2's unicode support is only so-so and whenever
> >>we get non-ascii or non-utf-8 encoded strings, we tend to run into
> >>trouble (the most common is problematic encoding seems to be
> >>latin-1). Given that Python's str type is really just a byte array
> >>with some built in smarts, it isn't really possible to guess what
> >>the encoding might actually be.
> >>
> >>To address this issue, I propose that we make string encoding as
> >>utf-8 a hard requirement on the server. To enforce this, we'll try
> >>to decode all strings from utf-8 and any failures will get a 400
> >>server response with some sort of standardized message: utf-8
> >>encoded strings only (dummy), or something similar.
> >>
> >>Any thoughts?
> >>
> >>Jason L Connor
> >>linear on freenode #pulp
> >>http://pulpproject.org/
> >>RHCE: 805010912355231
> >>GPG Fingerprint: 2048R/CC4ED7C1
> >>
> >>
> >>
> >>
> >>_______________________________________________
> >>Pulp-list mailing list
> >>Pulp-list at redhat.com
> >>https://www.redhat.com/mailman/listinfo/pulp-list
> >>
> >>
> >>_______________________________________________
> >>katello-devel mailing list
> >>katello-devel at redhat.com
> >>https://www.redhat.com/mailman/listinfo/katello-devel
> >
> >-James
> >
> >
> >
> >_______________________________________________
> >katello-devel mailing list
> >katello-devel at redhat.com
> >https://www.redhat.com/mailman/listinfo/katello-devel
> >
> 
> 
> -- 
> Jay Dobies
> Freenode: jdob @ #pulp
> http://pulpproject.org | http://blog.pulpproject.org
> 
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel

-James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/katello-devel/attachments/20121003/339e54b1/attachment.sig>