All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Lautrbach <plautrba@redhat.com>
To: Daniel Burgener <dburgener@linux.microsoft.com>,
	Vit Mojzis <vmojzis@redhat.com>,
	selinux@vger.kernel.org
Subject: Re: [PATCH] gettext: handle unsupported languages properly
Date: Wed, 29 Jun 2022 15:52:31 +0200	[thread overview]
Message-ID: <87tu83r2zk.fsf@redhat.com> (raw)
In-Reply-To: <871qvasere.fsf@redhat.com>

Petr Lautrbach <plautrba@redhat.com> writes:

> Daniel Burgener <dburgener@linux.microsoft.com> writes:
>
>> On 6/24/2022 1:27 PM, Vit Mojzis wrote:
>>> 
>>> 
>>> On 6/24/22 18:37, Daniel Burgener wrote:
>>>> On 6/24/2022 10:24 AM, Vit Mojzis wrote:
>>>>> With "fallback=True" gettext.translation behaves the same as
>>>>> gettext.install and uses NullTranslations in case the
>>>>> translation file for given language was not found (as opposed to
>>>>> throwing an exception).
>>>>>
>>>>> Fixes:
>>>>>    # LANG is set to any "unsupported" language, e.g. en_US.UTF-8
>>>>>    $ chcat --help
>>>>>    Traceback (most recent call last):
>>>>>    File "/usr/bin/chcat", line 39, in <module>
>>>>>      t = gettext.translation(PROGNAME,
>>>>>    File "/usr/lib64/python3.9/gettext.py", line 592, in translation
>>>>>      raise FileNotFoundError(ENOENT,
>>>>>    FileNotFoundError: [Errno 2] No translation file found for domain: 
>>>>> 'selinux-python'
>>>>>
>>>>> Signed-off-by: Vit Mojzis <vmojzis@redhat.com>
>>>>> ---
[...]
>>>>
>>>> Isn't the point of the overall change that gettext.translation() 
>>>> doesn't throw an exception anymore?  So we don't need to handle 
>>>> OSError/IOError here once fallback=True.  I see that this standardizes 
>>>> with the other call sites, but I wonder if standardizing on the more 
>>>> specific exceptions (or just leaving as is) wouldn't be better?
>>> 
>>> Yes, we do not need to handle OSError/IOError exceptions any more.
>>> I agree that standardizing on the more specific exception handling would 
>>> be more proper. However, translation handling is probably the least 
>>> important feature of this tool (most people probably use it in English 
>>> and those who don't wish they did) -- we don't want people to be unable 
>>> to use the tool at all because of some translation issue and "catch all" 
>>> exception handling is the easiest way to avoid that.
>>> As this bug showed, not settling on a single approach is probably the 
>>> worst alternative (I tested the previous patch with multiple tools, but 
>>> apparently missed the one that was different).
>>> 
>>> That being said, either approach is fine by me. Please let me know if I 
>>> should change the patch.
>>> Vit
>>
>> Well, I'll leave questions of what you *should* do up to the 
>> maintainers, but I think as far as I'm concerned your point that we 
>> really don't want to fail hard on translations makes a lot of sense (and 
>> I definitely agree that inconsistency is a pretty bad alternative.  So 
>> I'm on board with this approach.  I was initially worried about "what if 
>> in some future version gettext adds an exception?", but to your point, 
>> we want the same fallback logic in that case, so the general except 
>> seems reasonable.
>>
>> Reviewed-by: Daniel Burgener <dburgener@linux.microsoft.com>
>>
>
> Thanks!
>
> Acked-by: Petr Lautrbach <plautrba@redhat.com>
>
>


Merged.


      reply	other threads:[~2022-06-29 13:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-24 14:24 [PATCH] gettext: handle unsupported languages properly Vit Mojzis
2022-06-24 16:37 ` Daniel Burgener
2022-06-24 17:27   ` Vit Mojzis
2022-06-25  2:09     ` Daniel Burgener
2022-06-27  8:16       ` Petr Lautrbach
2022-06-29 13:52         ` Petr Lautrbach [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tu83r2zk.fsf@redhat.com \
    --to=plautrba@redhat.com \
    --cc=dburgener@linux.microsoft.com \
    --cc=selinux@vger.kernel.org \
    --cc=vmojzis@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.