On 8/20/2010 8:31 PM, Gale Andrews wrote:
> | From Vaughan Johnson <vaughan@...>
> | Fri, 20 Aug 2010 14:35:48 -0700
> | Subject: [Audacity-quality] "Show Log"
>> On 8/18/2010 1:53 PM, Gale Andrews wrote:
>>> | From Richard Ash <richard@...>
>>> | Wed, 18 Aug 2010 20:46:24 +0100
>>> | Subject: [Audacity-quality] "Show Log"
>>>> On Tue, 2010-08-17 at 16:08 -0700, Vaughan Johnson wrote:
>>>>> Btw, most (maybe all) of these are wrapped in wxT, so they don't get
>>>>> translated. I hate to add a burden on the translators, but I think they
>>>>> should be translated if the user is going to see them (i.e., wxLogDebug
>>>>> need not be translated because they appear only in debug builds, but the
>>>>> others should). Agree?
>>>> It would be nice, but it's not a high priority for translators. It also
>>>> reduces the googleability of the log messages. Pity there's no mechanism
>>>> for marking the "priority" of messages in the pot file so as to indicate
>>>> what is important (major parts of the UI) vs what is not so important
>>>> (rarely used error messages). Some sort of profiler for strings?
>>> Translating an Audacity warning like "Project check found inconsistencies
>>> inspecting the loaded project data" is OK, but I wouldn't think you'd want
>>> to translate any error that the OS produced, would you?
>> Those are generated within wxWidgets, and that code (e.g., "can't open
>> file...") already is marked for translation. So that's another reason to
>> mark ours for translation.
> What about for example "error 2: the system cannot find the file specified"
> that would be one explanation of "can't open file". Does that already appear
> in the native language of the OS when viewing the log?
The wxWidgets code is, e.g.,
wxLogSysError(_("can't open file '%s'"), filename);
...so they intend it to be translated.
But I traced this in Audacity code, and although Audacity was telling
wxWidgets to translate its strings, the Audacity code uses the wxLocale
constructor rather than wxLocale::Init, so never gets the failed result.
To support it, we'll need to keep current with
At this point, I think doing so is low priority, but please enter a bug
for it. I do think translating our log messages would be helpful, and
higher priority than getting wxWidgets' to work, but also low priority.
>When I answer
> questions in other than English, OS error text from various places is
> usually quoted in English (and up to a point that might make it easier for
> the user to find a search result for it, as Richard said).
>>> Another point IMO would be to raise the priority of getting the Manual
>>> translated, which I'd think should have priority over most parts of the
>>> translation except the UI. But the ad hoc Manual Wiki translating we
>>> have now doesn't seem to appeal much to current translators.
>> Different topic. Maybe start a thread on audacity-translation to get
>> ideas on that.
> Already did a while ago, but it only really produced some significant
> translations for the French Manual (plus an Italian standalone manual
> which I've not seen yet). Would be worth another shot when 2.0 is
> But I think it's partly relevant here too, because if we formalised a
> priority rating I think we'd want to have a rating for Manual and
> web site (e.g. simplistically it could be something like:
> 1) Menus/preferences/dialogues
> 2) Message boxes/alerts
> 3) Manual
> 4) Web site
> 5) Log messages )
I agree with that ranking.
> Obviously there are no strings for the Manual, but it makes the point
> to those who may be comfortable with Wiki translations, and the
> priority could be mentioned on:
> and at the top of both .pot files.
>>>>>>> Does it make sense to move it to the View menu, in the list with
>>>>>>> History, etc?
>>>>>> If it contains only error information, my slight preference would be that it
>>>>>> stays in the Help menu (and maybe it's called "Error Log").
>>>>> No, it still has several info-only messages, that I think the user will
>>>>> actually find useful (vs the ones about loading each component of
>>>>> FFmpeg, for example).
>>>> I think it does, in particular if I commit some of the local changes I
>>>> made to debug mixer toolbar issues which print quite a lot of
>>>> information about what devices are found and what we can control to the
>>>> log (and explain why sometimes the toolbar isn't there).
>>> Given some analogous information is in Audio Device Info, that again
>>> suggests to me that perhaps the Log should remain under Help.
>> I don't feel strongly about it, so okay. But it seems to me, then, that
>> Show Log should be grouped with Audio Device Info rather than with the
> I think it's accepted Help menu needs some tidying and possibly grouping
> of some items. +1 that the best place isn't with "Manual" and "Quick Help"
> as now.
I moved it to the bottom.