GNOME Bugzilla – Bug 134533
Message style in gnomemeeting.schemas.in.in is inconsistent
Last modified: 2020-06-06 16:29:41 UTC
The common style for schemas messages in GNOME that almost all modules use is to have <short> descriptions not end in a period, while the <long> descriptions should end in a period. I.e: <short>Enable foo</short> <long>Enable the foo functionality.</long> It seems that currently many messages in gnomemeeting.schemas.in.in don't follow this style; their long descriptions lack the ending period. Please note that string freeze is in effect and that fixing this now would need approval to break the string freeze.
Fabrice, do you know what the motive for removing ending periods were?
It was an error of mine, didn't verify the bug enhancement ( http://bugzilla.gnome.org/show_bug.cgi?id=119249 )i filled against HIG about that topic on bugzilla, and that i couldn't access my mail's archives about that. I was wrongly remembering that tooltips and schemas descriptions shouldn't end with final dots, making any difference between short descriptions and long descriptions.
Long descriptions are sync'ed with tooltips in the prefs window. It seems that tooltips should not end with a dot. But I'm not sure I understand Fabrice's comment, Fabrice, does that mean that you erroneously removed all dots and that we will have to put them back in 1.0.1 ?
Well seems that for those not sync'ed with tooltips (that's what confused me in removing or not the final dot), i removed them erroneously, not taking care that long descriptions should end witha dot.
We have an incoherence here. Either they all end with a dot, or they don't, but not a mix of both. I would give the priority to tooltips, so if tooltips do not end with a dot, and if we want to give less work to translators, then long descriptions should not end with a dot either and that bug should be closed. Or we choose that they should end with a dot and we add 108 messages to translate.
My way of doing this review was to remove them (primarily as some were also tooltips, and secondly because i didn't recheck the bug i reported in my first comment, that's why even those which are not sync'ed with tooltip don't have final dot) except for those containing more than one sentences. So i think the inconcistency is however present in whatever we'll do. It, imho, won't be nice to put long descriptions with more than one sentence without the second one ending with a final dot. But if we put again final dots at te end of long descriptions, we will have to desync the tooltips and anyways gives translators strings to translate in more. :(
Long schema descriptions should end in a period. Tooltips probably shouldn't. So there's not much to do about that -- the messages will have to be different. My past comment that preferences and schema messages should be identical if possible was only a recommendation, so as to not create too many messages for translators to translate, but not an absolute requirement. And one can still reduce work for translators by reducing the differences to a minimum. Msgmerge and fuzzymatching will handle the rest then, and work just fine as long as the changes are small. So I think this is ok: schema: "This enables the foo functionality." tooltip: "This enables the foo functionality" while I would recommend against having large differences like this: schema: "If enabled GnomeMeeting uses functionality foo." tooltip: "This enables the foo functionality" In the first case fuzzymatching will work so as to reduce the translator's work in updating the translation, in the second case much less so, due to the large differences. Anyway, now there is a string freeze so changing any of this is soo much post-freeze material now.
Somebody should do the changes for Ekiga 3.00.
Disregarding current string freeze: What to do now? Use own tooltip strings?
Why can't we simply have the same rule for long description in schemas and for tooptips? This reduces the amount of work for translators (even with fuzzymatching&Co.) and for developers (no need to synchronise them), the length of the po file etc. We can use a small code to obtain the schemas long description each time the tooltip is needed. And, as an example, in both of them add the dot when there are at least two sentences, and without dot when there is only one sentence.
Eugen, I agree with you.
I looked on texts in schemas and tooltip. I saw an example where they are not sync (enable_preview: "Video preview" compared to "Display images from your camera device"), there might be others. In order to remove the obligation for the programmer to synchronise these two strings, I propose that, for strings found in both tooltip and schema: - the string is put/modified in the schema only - for the tooltip, there will be a function which returns the text associated to the key, so instead of: tooltip = _("..."); gtk_widget_set_tooltip_text (..., tooltip); there will be: tooltip = get_tooltip_from_schema ("key_name"); gtk_widget_set_tooltip_text (..., tooltip); Note that this will NOT allow to automatically have schema long descriptions end in dot, while tooltips not (the function get_tooltip_from_schema could remove the final dot, if any); that would work in English, not necessarily in other languages. The drawback is that schema and tooltip will be exactly the same. We could give priority to tooltips, as shown in comment #5. I am not sure if this is an interesting thing to have. What do you think? I have not found on Internet something like this. I could implement it. If not, better to sync the strings (for after the string freeze :o( ).
Ekiga is not under active development anymore: https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/273 Ekiga saw its last release 7 years ago. The last code commits were 4 years ago. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (and transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active Ekiga development again in the future.