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

[Jay Dobies]

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 at redhat.com>
To: katello-devel at 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 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