Created attachment 242524 [details] [review]
Add translation markers to 2 user-visible strings

Review of attachment 242524 [details] [review]:

Good otherwise.

::: src/spice-display.vala
@@ -47,3 @@
             manager.auto_connect_failed.connect ( (dev, err) => {
                 var device_description = dev.get_description ("%1$s %2$s");
-                var box_name = config.last_seen_name?? "Unknown";

seems too vague for translators. Would be nice to add a comment for them.

Created attachment 242629 [details] [review]
Add translation markers to 2 user-visible strings

The strings were already present but not marked for translation.
This commit addresses that. I've checked with #i18n that this is
not considered a freeze break, and that it's not required that we
announce it either.

Review of attachment 242629 [details] [review]:

Sorry, I only noticed your commit log details now so I didn't know you intend to push this to stable branch. Could you explain a little how adding of new strings (untranslated strings do not exist from translators POV) is not breaking string freeze? This page seems to suggest otherwise: https://live.gnome.org/TranslationProject/HandlingStringFreezes

(In reply to comment #4)

> This page seems to suggest otherwise:
> https://live.gnome.org/TranslationProject/HandlingStringFreezes

You surely mean that this page confirms what I put in the commit log:

"The following types of changes do not need explicit approval, however we would still very much like them to be announced so that we know about them:

    Marking a message for translation that was previously not marked for translation by accident."

It seems the announcement is no longer strictly needed as they have a script doing that automatically. By "not considered a freeze break", I meant that we did not need to get authorization to mark the string as translatable.


Untranslated strings very much exist from a translator point of view as they are in the UI but they cannot translate it in their language. So marking it as translateable is an improvement for the translator (except that it brings down their language team stats ;)

(In reply to comment #5)
> (In reply to comment #4)
> 
> > This page seems to suggest otherwise:
> > https://live.gnome.org/TranslationProject/HandlingStringFreezes
> 
> You surely mean that this page confirms what I put in the commit log:

No, I just missed that peace of info. :)

> Untranslated strings very much exist from a translator point of view as they
> are in the UI but they cannot translate it in their language.

AFAIK, most translators don't use the software they are translating, at least not the unstable (or new stable) software whose translations they work on.

Review of attachment 242629 [details] [review]:

ACK

Arg, forgot to push that before 3.8.2

Attachment 242629 [details] pushed as e2758cd - Add translation markers to 2 user-visible strings