Include line numbers for strings like from i18n/en.yaml when extracting

[kisaragi-hiu]

Right now KDE website strings that come from i18n/en.yaml always end up with 0 as the line number. For example, this is an excerpt from documentation-develop-kde-org's PO template output:

#: i18n/en.yaml:0
msgid "Previous"
msgstr ""

#: i18n/en.yaml:0
msgid "Next"
msgstr ""

#: i18n/en.yaml:0
msgid "Read more"
msgstr ""

It turns out it's possible to augment PyYAML to include the line number information as a part of the output. By subclassing str to add just one property, other things treat it as a normal string while the extraction process can copy the line number to the POT file.

This PR also includes the key in i18n/en.yaml as context, as I find it actually useful when translating.

After this patch, the output for the same file becomes:

#: i18n/en.yaml:6
msgctxt "ui_pager_prev"
msgid "Previous"
msgstr ""

#: i18n/en.yaml:9
msgctxt "ui_pager_next"
msgid "Next"
msgstr ""

#: i18n/en.yaml:12
msgctxt "ui_read_more"
msgid "Read more"
msgstr ""

with the line numbers pointing to the right place (such as i18n/en.yaml:9) and the key being included as context.

[PhuNH]

Hey, thanks for this PR! I've been busy lately, will try to look at this in a few weeks. Meanwhile, could you check whether this still works fine with yaml config file and the frontmatter?

[PhuNH]

Another thing I can comment on right now is the making of yaml keys into message contexts: I think message comments would be more suitable for them now. Making them into contexts will add a context field to all the messages, making them all fuzzy, requiring translators to do something for them again while actually they aren't changed.

[kisaragi-hiu]

I'll test on KDE websites once I get the time to. This should only have an effect for files like i18n/en.yaml, but I haven't done a thorough enough check.

As for the key-as-context part: I didn't consider that that'd mark messages as fuzzy. I'll try putting them in comments and see how it works; if it requires too much work I'll split it into its own PR. (Ideally comments in the source yaml files would be copied over as well, but that's a lot harder as PyYAML discards comments)