Add W304 for untranslated messages

[jayvdb]

No description provided.

[willkg]

This change undoes part of this fix:

8a1d4a8

I haven't worked on a project that needed translations in 5+ years, so I'm pretty far removed from this space. I don't remember why we had so many fuzzy strings, but I do remember getting yelled at for trying to clean them up.

[jayvdb]

My guess is that the .po files contained lots of obsolete entries, as those can accumulate over time, and likely include strings which have become obsolete because of improvements due to linter results. I agree those shouldn't be linted by default. If that sounds like the problem, I can achieve both by either:

-for entry in po:
+for entry in [e for e in po if not e.obsolete]:

or

 for entry in po:
+    if entry.obsolete:
+        continue

For context, I am trying to implement untranslated detection so it can be used in CD to ensure that the .po files for certain languages have been updated to 100% translated before a release is deployed, and have warnings in CI to show which translations are still missing so they can easily be sent off to the translators (via Excel .. :/). dennis seems like a good fit because of its ability to also check for translation errors, and the current tool we're using isnt compatible with Django (ziima/polint#8).

[willkg]

I need to remember how the PO library Dennis uses works. I'll look at that and get back to this some time this week.

[willkg]

It's curious that polint doesn't document .fuzzy, .obsolete, and other flags on POEntry.

I think you're right on and we want something like:

for entry in po:
    if entry.fuzzy or entry.obsolete:
        continue

I think that does what .translated_strings() is doing now, except it'll let through strings that aren't translated which lets your rule work.

Does that sound ok?

[willkg]

I didn't know you updated the commit. I'll look at it later today.

[willkg]

This needs some tests so we know it's working as you expect and we know when some future change breaks it. We also need to document the new warning.

I think I can do both of those things, but I'll need you to review the work because there's no description in this PR and I'll be guessing at things based on the comments. Is that ok? Or would you rather do the tests and docs?

[jayvdb]

I am happy to add tests and docs.

[willkg]

FYI, I renamed the default branch to "main" and I transferred this project to the Mozilla org.