[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



Forwarding to the other mailing list on the original comment. Can we try to keep these to a single mailing list please? This conversation has been half in public and half internal, which makes for a confusing experience for our community.


-------- Original Message --------
Subject: Re: [katello-devel] Fwd: [Pulp-list] i18n input
Date: Wed, 03 Oct 2012 08:33:50 -0400
From: Jay Dobies <jason dobies redhat com>
To: katello-devel redhat com

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
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.

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.


-- bk



-------- Original Message --------
Subject: [Pulp-list] i18n input
Date: Tue, 2 Oct 2012 14:40:18 -0600
From: Jason Connor <jconnor redhat com>
To: pulp-list redhat com <pulp-list 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 redhat com
https://www.redhat.com/mailman/listinfo/pulp-list


_______________________________________________
katello-devel mailing list
katello-devel redhat com
https://www.redhat.com/mailman/listinfo/katello-devel

-James



_______________________________________________
katello-devel mailing list
katello-devel 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 redhat com
https://www.redhat.com/mailman/listinfo/katello-devel



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]