Last modified: 2013-04-02 02:08:04 UTC
Hi, I discovered this in a Spanish wiki. If '_CDAT' => 'Creation date', was not present in SMW_LanguageEs.php, the property was not properly generated after a Semantic MediaWiki refresh. Tested in SMW 1.7.1 By the way, this does not seem to be translated in translatewiki.net, does it?
Karsten any insights in terms of translations for this one?
I have recently completed the SMW language files to contain at least English versions for all untranslated property names: https://gerrit.wikimedia.org/r/#/c/31593/ With this the actual problem will be gone. The title of this bug is still true, so we may keep it open. I wonder if we could move to a message based translation for special properties anyway. This was not done originally due to performance problems with reading so many messages all the time. Maybe this needs to be revisited. An alternative would be to have a script that builds the language files automatically using messages. Then the files are like an PHP coded index for messages that we need a lot.
tw.n covers only the i18n located in the messages, aliases and magic file. Thus Toni's observation is correct. Actually I am surprised that we already have that many translations for this. I do not believe that something like this will be included into the localisation workflow in the foreseeable future.
Yes, that is what I meant. Hence it would be good to somehow integrate our code with the localisation workflow. There were three reasons for not doing this for the stuff in SMW_Language... so far: (1) Some messages are needed very early (e.g., namespace names) and it used to be a problem to get messages at this stage of initialisation in the early days at all. (2) Some messages need efficient inverse lookups. Given a user input, we need to find the special property message or alias that it belongs to. Doing this by cycling through all potential candidate messages seemed wasteful. (3) The files do not have a fixed number of strings that they define. For example, it is unknown how many aliases some property should have (if any). To encode this in messages, one would need to ask translators to format their translations as a comma-separated list (or similar). Not sure if this works well. A similar situation is with the preferred date formats (day-month-year vs. month-day-year etc.), which are defined as an ordered list of format strings. Could be confusing for translators. We could solve (1) and (2) by having a script that reads the messages to build PHP files that can be used for fast lookup. Alternatively, we could build this code every time it is needed, but this might not be very efficient, even if the retrieval of messages is efficient now.
Perhaps there is a way to include these into the regular messages file and to let SMW pick them up there.
Removing this as blocker for 1.9, not sure why it was one
