Messages customization statistics

Edited by author.
Last edit: 17:29, 7 April 2011
  • Messages are often modified, even thought the wording is identical. These can probably be deleted in the project, because otherwise they won't be updated when they are updated in the software.

These may be modifications that admins were waiting for too long. Best make them aware, I'd suggest.

  • Modified messages often differ very little from the original. For example, the original may have a period or a colon in the end, and the modified messages doesn't ...

Probably worth investigating. May happen with translations made here, too, since adding/deleting a colon often does not lead to fuzzying. So it may be translatewiki.net that errs.

  • For example, in en.wp "content page" is replaced with "article" ..., so maybe this could be parametrized.

I think, it is worth thinking this over. Rotem Liss, Gangleri, me, and possibly others had been proposing this already before translatewiki.net begun as betawiki, but it has been deemed "too expensive" by other developers. I am currently contemplating a kind of offline MessageXzz.php file preprocessor or converter, that may be able to make such changes as well - a kind of prompted general search and replace operation. This may become increasingly impractical, to moer messages are amended or added over time, and the more extensions are being used in a wiki. So I am not really happy with this kind of approach.

  • Can anyone create statistics of modified messages ...

Imho, this is a typical toolserver project, and it is not hard to make at least a simple working prototype. If I had the time atm, I'd give it a try, but there are likely more ones who can do that, too. Maybe, you wanna try the toolserver mailing list ?

Purodha Blissenbach15:55, 6 April 2011

Messages are often modified, even thought the wording is identical. These can probably be deleted in the project, because otherwise they won't be updated when they are updated in the software.

These may be modifications that admins were waiting for too long. Best make them aware, I'd suggest.

The modifications could have been done manually in the project, as suggested above, but I seem to remember that we were told it is a quirk of 'Localisation Update' extension, that it sometimes generates these duplicates. The advice when 'Localisation Update' was first introduced was to delete the duplicate messages in the project manually because there wasn't a way to do it automatically back then, if I remember right.

Lloffiwr17:14, 7 April 2011