Use of abbr tag in EXIF message
Hi friend. Is the following usage permitted [1] since the abbreviation is not familiar in the target language?
I took the opportunity to suggest that such things be generally accepted in i18n.
Notwithstanding the above comments, I can see no reason why the translations of the above message have to use an abbreviation instead of the whole translation of counterclockwise. Assuming that the translation appears in an exif data box, as in this example, I can see no need to keep the translation short.
Furthermore, my personal preference would be to see CCW replaced by counterclockwise in the English version also. CCW may very well be an accepted abbreviation within photographic and computer circles, but wikis are generally supposed to be accessible to the general public, so if space is not short, why not write the whole word?
Sometimes, the number of characters to use is limited...
I have added an FAQ on using the abbreviation tag in MediaWiki. Please amend or expand, as needed. In MediaWiki, is there a way for us to know whether it is possible to display abbreviation tags in a particular extension, and is it always available in core messages?
Is it only MediaWiki that has this option, or do some of our other projects have a way to add an annotation? If so, can we document this too, so that we know the option to annotate a word or abbreviation is available for a particular project.
In mediawiki it's not per extension, it is per message. Most messages don't allow <ab br>, because they are not even outputted in html context.
What a shame. Is there a practical way to add documentation to each message which does allow <ab br>, to say that it does allow <ab br>? If not, perhaps it would be better not to have the FAQ on this at all, if it is going to raise translators' hopes in vain.
Also, if not, is it possible to request that an annotation feature be available for all messages? this could add a lot of flexibility for translators, especially in languages which need to coin new technical words during translation.
Is this something that we could request for other projects also?
This has been requested before, but nobody has done it. The problem is that any automatic way of collecting that information is not going to find it for all messages, maybe not even half.
What is annotation feature?
Agreed with Nike, we could document at best half of the messages in MediaWiki and its extension in an automated way, telling whether or not they accept html inline markup, and whether or not they are being used in an html context. I tried to develop a simple text based xref tool which would be able to list which message key is/was used where (per file name and revision number) in the subversion repository, which could also collect some usage type information. I gave up because even identiying message keys is often impossible without "understanding" the "meaning" of program code. For example $abc='nuke' in one place and $messagestring=wfMsg($nuke.'-desc') in another is too hard for a text based analyzer program looking for occurrances of a message key 'nuke-desc', and we have too many more complicated cases than this.
It is worth noting usage informations in the message documentation, when it is obvious that it will not change, such as "this the body of an e-mail sent to users when…" - the use as an e-mail body implies that html must not be used.
Else, developers alter things like whether inline html makup is accepted or not. I do, for example. There are places where html inline markup is unproblematic but not (yet) supported, and others where a change would be either insecure or call for large amounts of work. If you find instances of messages where you would recommend using html markup and it does not work, let us know via the support page. Odds are, that a change would be simple and doable. Inside tabular structures and inside links and headlines that is sometimes not so, or at least not easy. Filing a bug at buzilla may alert developers who know the particular piece of code well enough to make the change. If you file such bugs, please mark them with the keyword i18n so that we more easily find them.