Re: Boxes: string breaks



Hi Alexandre,

On Mon, Sep 14, 2015 at 8:24 PM, Alexandre Franke
<alexandre franke gmail com> wrote:
On Mon, Sep 14, 2015 at 8:54 PM, Zeeshan Ali (Khattak)
<zeeshanak gnome org> wrote:
I asked as soon as I had the patch and not long after I knew how I'm
going to solve this in the end (i-e when I knew how strings will be
effected).

I wasn't blaming you for waiting, I was just stating the fact that now
is not the best time to introduce new strings.

Sorry if it felt like I was implying you were blaming me. :) I just
felt like I should explain myself.

I provided a link to attachment. I would have done a better job if I
didn't realize this is coming in very late.

My point is if you're asking for something, you better make a good case for it.

Indeed.

Adding:
#. Translators: First '%s' is name of box and second one is it's
status (e.g 'connecting...')
msgid "%s: %s"

Replacing
#. Translators: The %s will be expanded with the name of the vm
msgid "Restoring %s from disk"
with
#. Translators: Shown when restoring a box from a saved state
#: ../src/libvirt-machine.vala:588
msgid "Restoring state…"


Replacing
#. Translators: The %s will be expanded with the name of the vm
msgid "Starting %s"
with
#. Translators: Shown when starting a box
#: ../src/libvirt-machine.vala:591
msgid "Starting…"

Replacing
#. Translators: The %s will be expanded with the name of the vm
msgid "Connecting to %s"
with
#. Translators: This is shown when connecting to a box
msgid "Connecting…"

Summary: 4 new strings.

Yeah.

nor explain why we should grant you an
exception,

Same reason and I see a few other issues I really should fix before
code freeze. You can find the rationale on the bug description:

The question is not only "what are you changing/adding?" but also "can
you tell us why this is important to get in now rather than in the
next release?". In other words, please justify why you think an
exception is needed.

I usually tend to always have rationale around. As you replied below,
the bug description contains the rationale, though not very specific
enough for translation team to make an informed decision on, I must
admit.

"Unifying 'status' of machines caused some issues and the one that's
not yet resolved is us showing "Connecting to '%s'" and "Restoring
'%s'" in collection views, where it doesn't completely fit in the
available space usually and also it looks odd given that name of the
machine is already shown in the context and is clear to user.

Let me check if I get this right: the issue is that the English string
doesn't fit in the allocated space?

No, that is just one of the issues and it's that string almost never
fits in it's space (which is much worse than it not fitting in
sometimes). The major one is that it's displaying redundant info that
makes the label really odd.

In this case, do you really thing
just changing the strings is the correct way to handle this?

I have another fix too but it might be hard to implement and/or cause
ugly code. I'll look into that and see if we can go with that. Maybe I
can go with ugly code for 3.18.

Remember
that you're talking to translators here and what works with the
original strings in English might not work in other languages. You
can't reasonably expect that because the English string is short, the
translation will always be as short,

1. I'm not expect the string to always fit the label size. The string
will be ellipsized if it doesn't fit the allocated width.
2. All these strings are pretty small (1 verb) and there is plenty of
space available so I'm sure at least most translations will fit in.
3. We always have some specific width given to labels in our UIs so
some specific translations not fitting in the allocated width, is
quite a generic issue IMO. I wish devs had an easy way to know if some
specific translation didn't fit the label so they can possibly do
something about it.

-- 
Regards,

Zeeshan Ali (Khattak)
________________________________________
Befriend GNOME: http://www.gnome.org/friends/


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