[MPlayer-dev-eng] [PATCH] printf -> mp_msg

[The Wanderer]

Reynaldo H. Verdejo Pinochet wrote:

> On Sun, Mar 19, 2006 at 07:24:37PM +0100, Ötvös Attila wrote:
> 
>>Hi All!
>>
>>Files:
>>
>>[cut]
>>
>>Best regards!
>>Attila
> 
> * Not really sure but:
> 
> - MSGTR_MPLIBAO2_UnkkownSupportedOSSFromat "Unknown/not supported OSS format: %x\n"
> + MSGTR_MPLIBAO2_UnkkownSupportedOSSFromat "Unknown/Not supported OSS format: %x\n"

The original form isn't ideal, but the new form isn't an improvement;
the "Not" should not be capitalized. The better fix would be to say
"unsupported" instead, for parallelism with "Unknown".

(Also, the MSGTR name uses "Unkkown"; looks like a typo, but depending
on how many places this is used the fix might be intrusive enough to not
be worthwhile.)

> * Just to stay consistent with:
> MSGTR_MemAllocFailed "Memory allocation failed\n":
> 
> - MSGTR_LIBMENU_MallocError "malloc error: %s"
> + MSGTR_LIBMENU_MAllocError "Memory allocation error: %s"

This is not necessarily correct, depending on whether or not the "memory
allocation" referred to in MemAllocFailed is done with malloc. From the
MSGTR names, it looks as if the former could be referring to any memory
allocation, and the latter only to malloc. This is, however, minor.

(If such a change *is* made, incidentally, I would recommend extending
the MSGTR to MSGTR_LIBMENU_MemAllocError - rather than just capitalizing
the A - for consistency with the example you gave.)

> * Check phrasing on this ones:
> 
> MSGTR_LIBMENU_MenuTxtNeedATxtFileName "Menu txt need a txt file name
> (param file)\n" (sounds weird)

Very. I have no idea what it even *means*, so I can't really try to
rephrase it. Is it talking about a file called "menu.txt", or does it
want the word "text" there, or is there something I haven't thought of?

In any case, instead of "txt file", it should be either "text file" or
".txt file".

> MSGTR_LIBMENU_MenuTxtCantOpen "Menu txt can't open: %s\n" (sounds weird)

Same problem here, I don't know what it means.

> MSGTR_LIBMENU_WarningTooLongLineSplitting "Warning too long
> line, splitting it\n" (Warning, string too long, splitting it ?)

Both forms have comma issues, and yes, "too long" should come after the
noun rather than before. The comma issues could be avoided perhaps most
simply by replacing the latter with an emdash, of whatever form is
preferred.

> MSGTR_LIBVO_Dxr3UseUnknownNormSuppliedCurrentNorm "Unknown norm
> supplied. Use current norm" (Using ?)

Again, I don't know what this means, because I don't know what a "norm"
is in this context.

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.