Internationalization - several strings that haven't been offered on translation page

Sorry, I made an error in '3.

There's only one line that hasn't been offered for translation, and it's

Server uptime: 05:02 up 2 days, 5:00, load average: 0.25, 0.16, 0.06

Sorry for writing my post in three parts, but I happened to figure something out. The following refers to problem '2.

The translator -could- make all the colons aligned by carefully putting the right amount of blank spaces in front of all the translated strings. However, it's a difficult and lengthy way of doing it, and it's questionable whether all translators would be patient enough to do it that way. Perhaps it would be good to modify the source to automatically align the colons so that the translators don't have to do it manually.

It seems that the message that's used by the server in problem 1. is used for sending any error message related to the invalid amount of arguments given to the function. If that message is added to the translation page, all messages which have this problem will probably be fixed.

Also, I've found some more messages that haven't been offered for translation:

5.

If one uses

@cpattr <object>/<attribute>=<new object>/<new attribute

the response on a server using translated messages is:

Attribute <copied> (1 copies)

The entire message is translated, except the word in <>s (copied).

6.

A problem similar to the one with @cpattr occurs when one types:

@mvattr <object>/<attribute>=<new object>/<new attribute

The response is:

Attribute <moved> (1 copies)

Everything is translated in that server message, except the word 'moved'.

7.

When one types:

whisper <player>=<text>

the player receiving the whispered message will see:

<enactor> whispers: <text>

This string hasn't been offered for translation, so 'whispers' is untranslated in the above message.

8.

There's another, more complicated, problem with 'whisper'. If one types:

whisper <player>=<text>

the player sending the whispered message will see:

You whisper, "<text>" <to> <player>

This string -has- been offered for translation, and 'You whisper' -is- translated, but the word 'to', which I've put in <>s, is still there, in English.

9.

There's a lot of untranslated things which one could see with

@config

and

@config/list <option>

In plain @config, the descriptions which are right of every option in the options' list are untranslated.

In @config/list, first line of outputted text obtained by specifying any option will be in English. Another problem, which perhaps isn't a problem, is that 'Yes' and 'No' displayed right of the config option names displayed with @config/list are untranslated. Perhaps it's okay that they're untranslated, because they're expected to be 'yes' or 'no' in the config file itself. I'd leave it to the devs to decide if 'Yes' and 'No' should be translated or not.

Here's more server messages in which translations are non-existing or problematic:

10.

@wizwall <text>

Response:

Broadcast: %s says, "%s"

The above message wasn't offered for translation.

11.

Command:

@wall <text>

Response:

Announcement: %s shouts, "%s"

That one hasn't been offered for translation either.

12.

There's a problem with

@sitelock

when used without arguments. Here are the exact last two lines I get when I use @sitelock on a MUSH that uses internationalization:

2 SITE: *static.mesanetworks.net DBREF: #-2 FLAGS: !guest
COMMENT: By Jurica(#3) on Fri Jun 08 22:19:47 2007

Server messages of this type which are displayed by @sitelock haven't been offered for translation.

13.

When one types

@search

several things in output are untranslated. These captions are untranslated:

ROOMS:
EXITS:
THINGS:
PLAYERS:

Also, lines such as these aren't translated:

%s [owner: %s]
%s [from %s to %s]

14.

There's a complicated problem with

@atrlock <object>/<attribute>

and I'm not sure if it should be solved or not, because it's possible it isn't really a problem, because it could be solved by not translating the word 'locked'. The translations for all messages returned as responses to this command do exist.

The server uses the same string to state that an attribute is locked and that attribute is unlocked. It's

That attribute is %slocked

If the attribute is unlocked, the server will add a 'un' in place of %s. It won't add anything if it's locked. The problem is that the translators have only that %s to work with, and the %s will return either nothing or 'un'. All translators except me have left 'locked' in its original English form, and that's why their translations have no problem. My translation does have a problem, because I translated 'locked'. English is probably the only language in which the word for 'locked' can be negated by prefixing it with 'un'. Some of the other languages have another prefix which negates it, while other languages make more complex changes in the word for 'locked' to translate it. Either the translations for all languages will have to use 'locked' in its original form, or two separate message strings should be used, one for the case in which the attribute is locked, and the other for the case in which the attribute is unlocked. So, I suggest that

That attribute is %slocked.

Gets replaced with

That attribute is locked.
That attribute is unlocked.

15.

There's a somewhat weird problem with

@create <object>

One gets:

Created: Object <dbref>

and that message isn't translated. The weird thing is that the above server message -has- been offered for translation, and that it exists in the .po files. Regardless, the message sent by the server is still in English.

16.

@edit <object>/<attribute>=<old>,<new>

returns

<attribute name> - Set: <new contents of the attribute>

The above string wasn't offered for translation.

17.

If one types:

look <player>

the following line won't be seen translated:

Carrying:

What's weird is that 'Carrying:' was offered for translation, and the translation -does- show up when one does 'examine <player>'.

18.

When one types

@entrances

last line will be seen untranslated:

Totals: Rooms...%d Exits...%d Objects...%d Players...%d

Also, lines such as these weren't offered for translation:

<player> [home]
Exit Name [from: Room Name]

19.

@force <nonexisting object>=<action>

There are two lines of output. The second one says

Sorry.

That one wasn't offered for translation.

20.

@sweep

Some things in the output are translated. The untranslated things in output are

[speech]
[commands]
(connected)

which are displayed in the outputted list obtained by @sweep.

21.

@use <object>

returns

Used.

if object's @use attribute isn't set. 'Used.' wasn't offered for translation.

22.

@config/<commands|functions|attribs>

returns untranslated output, in the form:

Commands: %s

Functions: %s

Attribs: %s

Those strings weren't offered for translation. @config/flags' output -is- translated.

23.

@chan/list

There's a problem in the first line of the above command's output. All column names except 'Chan Type' are untranslated because they weren't offered for translation.

Also, there's a problem in the channels' list given by this command. 'On' and 'Off' in the 'Status' column weren't offered for translation, and are still displayed in English.

Thanks for these! I'll go through and mark as many of these as possible for translation sometime before the next releases.

1: Fixed

2: I'm not sure of an easy way to fix this one. Will think more.

3: Fixed by someone else, I think; the appropriate strings are tagged already.

4-8: Fixed

9: Marked the descriptions of categories as translatable. Should the categories be too? Need to look into if that will break @config/list

10,11: Fixed, kinda. What about languages with different grammar than english? How does gettext play with printf?

13: Fixed

15-22: Fixed

23: Fixed, but it'll hit the same alignment problems as @uptime and anything else with tabular output that uses a fixed-with column size.