Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update po files for special ability notes' bullets #4297

Open
jostephd opened this issue Aug 31, 2019 · 19 comments

Comments

@jostephd
Copy link
Member

commented Aug 31, 2019

Split from #4231 (comment) @Wedge009

In 1.15 the special notes are shown as bullets (093fbc8). This invalidated translations. Can we somehow make translations valid again, for example, by inserting the newline + bullet into all translations?

I made the original change and I'd be happy to make some fix in all translations, but I'm not sure how to do that. Would I just mass-edit the po files? Can I just do this at any time? There was a pot-update recently (4830c76) and we aren't in string freeze on master so I guess now would be a good time?

@jostephd

This comment has been minimized.

Copy link
Member Author

commented Aug 31, 2019

@Wedge009 suggested to use pofix. However, we'd need to add a newline too; would that be a problem?

@jostephd

This comment has been minimized.

Copy link
Member Author

commented Aug 31, 2019

Should I just commit the following change (but extended to all special notes and all po/pot files)?

diff --git a/po/wesnoth-httt/en_GB.po b/po/wesnoth-httt/en_GB.po
index c3612d4d940..771539b55a6 100644
--- a/po/wesnoth-httt/en_GB.po
+++ b/po/wesnoth-httt/en_GB.po
@@ -8823,15 +8823,12 @@ msgstr ""
 "defending."
 
 #: data/campaigns/Heir_To_The_Throne/utils/abilities.cfg:18
-#, fuzzy
-#| msgid ""
-#| " This unit's grasp of melee tactics allows adjacent allies to strike the "
-#| "first blow even when defending."
 msgid ""
 "\n"
 "• This unit's grasp of melee tactics allows adjacent allies to strike the "
 "first blow even when defending."
 msgstr ""
+"\n•"
 " This unit's grasp of melee tactics allows adjacent allies to strike the "
 "first blow even when defending."
 
@Wedge009

This comment has been minimized.

Copy link
Member

commented Aug 31, 2019

For the mgstr, should use whatever was there before the po-update that made it fuzzy. But I believe that's essentially what needs to be done. I don't know if this could all be undone in a subsequent po-update, though, hence why I thought it should be done with pofix, but I'm no expert there either.

@jostephd

This comment has been minimized.

Copy link
Member Author

commented Aug 31, 2019

That's a good point, I shouldn't remove the fuzzy marking if the string had been marked fuzzy prior to the pot-update. I'll await guidance.

@CelticMinstrel

This comment has been minimized.

Copy link
Member

commented Aug 31, 2019

The reason for pofix is that if you just edit the po files directly, your work will be overwritten next time Ivanovic commits the latest translations.

So I wouldn't recommend anything that involves directly editing po files. If possible, I think you should find a way to use pofix. If it's not possible you could always try extending pofix so that it is possible. But, I think adding a newline should be possible somehow...

@jostephd

This comment has been minimized.

Copy link
Member Author

commented Aug 31, 2019

But pofix only changes msgid's, not msgstr's...

@CelticMinstrel

This comment has been minimized.

Copy link
Member

commented Aug 31, 2019

Well, the fact remains that any attempt to manually update the po files risks being overwritten the next time Ivanovic pushes new translations.

@jostephd

This comment has been minimized.

Copy link
Member Author

commented Aug 31, 2019

@ivanovic What would be the best way to handle 093fbc8 in the po files?

@CelticMinstrel

This comment has been minimized.

Copy link
Member

commented Aug 31, 2019

For the record, I'm not even entirely convinced that bullets are workable for all languages, so it might be best to just let the maintainers handle it themselves.

If we had the new special_notes= key that I'd been planning to add in various places for forever, this would be quite a bit easier – the bullets could be removed from the translatable strings and automatically added in by the help topic generator. (The bullet itself could then be made a separate translatable string if any translator complains it's not suitable to their language.)

@Wedge009

This comment has been minimized.

Copy link
Member

commented Aug 31, 2019

I agree that would be a better solution: to have the bullets added by the special notes handler rather than tacked on to the string itself.

@CelticMinstrel

This comment has been minimized.

Copy link
Member

commented Aug 31, 2019

Well, I think part of my original plan was to add a way to place special notes directly in the unit definition (for the cases of special notes not directly linked to an ability, race, damage type, or whatever else which provides an obvious external location for it). So perhaps what we could do for now is add a new [special_note] tag to [unit_type] which could be used to append special notes, and use that for all the special notes. (It has to be a tag even though there's only one subkey because we need to accept multiples of them and comma-separated notes would be pretty terrible to work with.)

@jostephd

This comment has been minimized.

Copy link
Member Author

commented Sep 14, 2019

After #4305, there's still a difference translators will be faced with:

#define SPECIAL_NOTES_ARCANE
_" This unit’s arcane attack deals tremendous damage to magical creatures, and even some to mundane creatures."#enddef

#define INTERNAL:SPECIAL_NOTES_ARCANE
_"This unit’s arcane attack deals tremendous damage to magical creatures, and even some to mundane creatures."#enddef

It's the leading space...

I guess we should remove the leading space from all translations simultaneously? I can look into that after string freeze starts tomorrow if somebody gives me the go ahead that it won't conflict with translators' work? Alternatively we can add # po: A leading space was removed. comments to the INTERNAL:* strings, so translators won't be confused by an apparently correct translation being marked fuzzy.

edit: Deleted statement about 1.14 string freeze

@Wedge009

This comment has been minimized.

Copy link
Member

commented Sep 14, 2019

Doesn't the string freeze only apply to the text in cfg source and not the generated po files? Anyway, looks like we're back to the original problem of updating the po files in such a way as to not invalidate the existing translations, yet not risk having that fix be overwritten by the next pot-update.

@CelticMinstrel

This comment has been minimized.

Copy link
Member

commented Sep 15, 2019

I don't think it matters that much if translations have an extra leading space… true, it would cause the strings to be marked fuzzy, but I'm pretty sure the translators would be able to quickly spot that the translation is still correct and remove the fuzzy label?

@jostephd

This comment has been minimized.

Copy link
Member Author

commented Sep 15, 2019

@Wedge009 Yeah, I think I was confused about the order of events. A mass fix would need to happen before string freeze is announced to translators to prevent conflicts, that's what I was trying to say.

@CelticMinstrel I don't know... but if you're right, we can just close this issue.

@soliton-

This comment has been minimized.

Copy link
Member

commented Sep 15, 2019

https://wiki.wesnoth.org/Translation_Maintainance_Commands#updating_po_files_for_committing pofix is run before committing translation updates.

@Wedge009

This comment has been minimized.

Copy link
Member

commented Sep 16, 2019

celmin, if these were small strings it might be obvious that the change is trivial and fuzzies can be marked as done. But the notes are fairly long and translators may re-check the whole string if they're keen on being thorough, just in case there was any small change they might have missed.

I suppose we can just include an advice in the next translation e-mail that these strings have been trivially updated and don't need explicit reviewing.

@sevu

This comment has been minimized.

Copy link
Member

commented Sep 16, 2019

Poedit shows if there are inconsistencies in how a string starts or ends between original and translation – it shows differences in spaces or punctuation, so it should be easy to spot.

Pofix on the other hand is a tool for a different issue – when you do not want to change the translations, but the original.

I suppose we can just include an advice in the next translation e-mail that these strings have been trivially updated and don't need explicit reviewing.

That sounds like the best way to go.

@soliton-

This comment has been minimized.

Copy link
Member

commented Sep 16, 2019

Pofix is used when you want to change the original string and not bother translators because the meaning did not change. That is the goal here AFAICT. Most important for this is to fix the msgid to the new string, i.e. remove the leading space.

Nice to have in this case would perhaps be to also automatically remove the space from the translation, i.e. msgstr. Since pofix normally replaces fixed strings and the translations are of course not fixed that would need additional logic which may be considered too fragile/complicated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.