#15253: No translation in osx trunk

[wxTrac]

Ticket URL: <http://trac.wxwidgets.org/ticket/15253>

#15253: No translation in osx trunk
--------------------------+-------------------------------------------------
Reporter: raananc | Owner:
Type: defect | Status: new
Priority: normal | Milestone: 2.9.5
Component: translations | Version:
Keywords: | Blockedby:
Patch: 0 | Blocking:
--------------------------+-------------------------------------------------
My application, generated under osx 10.6.8 with 2.9.4 (osx/cocoa)correctly
translates strings using .po file.

The application checks for the presence of the translation file and
verifies that its size is correct.

Exactly the same application was regenerated and linked with a fresh
generation of wxWidgets (svn 74237). The only difference is the wxWidgets
version path.

The application identifies the system language correctly (the right-
language help file is displayed), but no translation is carried out even
though the same .po file is present in the application package.


--
Ticket URL: <http://trac.wxwidgets.org/ticket/15253>

[wxTrac]

Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:1>

#15253: No translation in osx trunk
--------------------------+-------------------------------------------------
Reporter: raananc | Owner:

Type: defect | Status: infoneeded_new

Priority: normal | Milestone: 2.9.5
Component: translations | Version:
Keywords: | Blockedby:
Patch: 0 | Blocking:
--------------------------+-------------------------------------------------

Changes (by vadz):

* status: new => infoneeded_new


Comment:

Sorry, I really don't know what could be wrong with your application.
Could you please test the internat sample included in wxWidgets? Does it
work for you? If it does, what does your program do differently?


--
Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:1>

[wxTrac]

Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:2>

#15253: No translation in osx trunk
--------------------------+-------------------------------------------------
Reporter: raananc | Owner:

Type: defect | Status: infoneeded_new

Priority: normal | Milestone: 2.9.5
Component: translations | Version:
Keywords: | Blockedby:
Patch: 0 | Blocking:
--------------------------+-------------------------------------------------

Comment(by vaclavslavik):

Try enabling i18n trace messages to see what catalogs are seen and loaded
(or not).

Also, could this be related to #15257?


--
Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:2>

[wxTrac]

Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:3>

#15253: No translation in osx trunk
--------------------------+-------------------------------------------------
Reporter: raananc | Owner:
Type: defect | Status: new
Priority: normal | Milestone: 2.9.5
Component: translations | Version:
Keywords: | Blockedby:
Patch: 0 | Blocking:
--------------------------+-------------------------------------------------

Changes (by raananc):

* status: infoneeded_new => new


Comment:

I would be glad to enable i18n trace messages, but have no idea how to and
where to look for the log file.

The relevant code in my application is:

{{{
.h file
wxLocale* locale;

.cpp file
locale = new wxLocale(wxLANGUAGE_DEFAULT, wxLOCALE_LOAD_DEFAULT );

currentLanguage = locale->GetSystemLanguage();

if (currentLanguage == wxLANGUAGE_FRENCH)
{
catalogPath = applicationPath + "fr";
locale->AddCatalogLookupPathPrefix(catalogPath);
locale->AddCatalog("gestioncomptes");
}
}}}
The only thing which changes between the 2.9.4 generation and the 2.9 svn
generation is the application within the package. With both versions,
currentLanguage returned by Locale is 80 (French), which is my Mac's
language. Thus, the situation is similar to the analyses in [ticket:15257
#15257.]

The MO file used in both cases was created by Poedit 1.5.5. on Windows 8.

Just to be sure, I generated the MO file on OSX 10.6 using the Mac version
of Poedit 1.5.5, but this does not solve the problem.


--
Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:3>

[wxTrac]

Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:4>

#15253: No translation in osx trunk
--------------------------+-------------------------------------------------
Reporter: raananc | Owner:
Type: defect | Status: new
Priority: normal | Milestone: 2.9.5
Component: translations | Version:
Keywords: | Blockedby:
Patch: 0 | Blocking:
--------------------------+-------------------------------------------------

Comment(by vaclavslavik):

Replying to [comment:3 raananc]:

> I would be glad to enable i18n trace messages, but have no idea how to
and where to look for the log file.

See the referenced bug: enable trace messages by setting WXTRACE
environment variable to "i18n" and look at the console output.


--
Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:4>

[wxTrac]

Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:5>

#15253: No translation in osx trunk
--------------------------+-------------------------------------------------
Reporter: raananc | Owner:
Type: defect | Status: new
Priority: normal | Milestone: 2.9.5
Component: translations | Version:
Keywords: | Blockedby:
Patch: 0 | Blocking:
--------------------------+-------------------------------------------------

Comment(by raananc):

I guess you know OSX better than me; would you be so kind and specify to a
mac non-expert where to add the environment variable (my mac is running
osx 10.6.8).

I tried to add it to DialogBlocks plist but couldn't. I looked at
/etc/config and it is empty.

Thanks.


--
Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:5>

[wxTrac]

Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:6>

#15253: No translation in osx trunk
--------------------------+-------------------------------------------------
Reporter: raananc | Owner:
Type: defect | Status: new
Priority: normal | Milestone: 2.9.5
Component: translations | Version:
Keywords: | Blockedby:
Patch: 0 | Blocking:
--------------------------+-------------------------------------------------

Comment(by vadz):

Set it from the command line (`export WXTRACE=i18n`) and run the
application from the (same) command line, e.g.
`./MyApp/Contents/MacOS/MyApp`.


--
Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:6>

[wxTrac]

Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:7>

#15253: No translation in osx trunk
--------------------------+-------------------------------------------------
Reporter: raananc | Owner:
Type: defect | Status: new
Priority: normal | Milestone: 2.9.5
Component: translations | Version:
Keywords: | Blockedby:
Patch: 0 | Blocking:
--------------------------+-------------------------------------------------

Comment(by raananc):

Trace file is enclosed

(just as a reminder for future referece: bash does not recognize 'export'
; to use 'export' must run sh)


--
Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:7>

[wxTrac]

Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:8>

#15253: No translation in osx trunk
--------------------------+-------------------------------------------------
Reporter: raananc | Owner:
Type: defect | Status: new
Priority: normal | Milestone: 2.9.5
Component: translations | Version:
Keywords: | Blockedby:
Patch: 0 | Blocking:
--------------------------+-------------------------------------------------

Comment(by raananc):

Added TraceDebug294, which is the trace of the same application generated
with 2.9.4

Obviously, this time the language identifier is correct, and the
application displays the translated messages.


--
Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:8>

[wxTrac]

Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:9>

#15253: No translation in osx trunk
--------------------------+-------------------------------------------------
Reporter: raananc | Owner:
Type: defect | Status: new
Priority: normal | Milestone: 2.9.5
Component: translations | Version:
Keywords: | Blockedby:
Patch: 0 | Blocking:
--------------------------+-------------------------------------------------

Comment(by vaclavslavik):

Replying to [comment:3 raananc]:

> {{{

> currentLanguage = locale->GetSystemLanguage();
>
> if (currentLanguage == wxLANGUAGE_FRENCH)
> {
> catalogPath = applicationPath + "fr";
> locale->AddCatalogLookupPathPrefix(catalogPath);
> }}}

Why do you do this at all? All of this could be replaced with simple
`locale->AddCatalogLookupPathPrefix(applicationPath)` (and better yet,
this should be completely removed and you should install the languages in
Resources folder). Basing the UI language on `locale->GetSystemLanguage()`
is wrong too, as explained in #15257.

Anyway, I think (but didn't yet verify) that the problem is that scanning
for he catalogs fails to recognize the language when its part of the
`AddCatalogLookupPathPrefix` path, instead of being discovered. I'd
consider this a misuse of the API myself, but I'll see if it can be fixed
reasonably easily.


--
Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:9>

[wxTrac]

Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:10>

#15253: No translation in osx trunk
--------------------------+-------------------------------------------------
Reporter: raananc | Owner:
Type: defect | Status: new
Priority: normal | Milestone: 2.9.5
Component: translations | Version:
Keywords: | Blockedby:
Patch: 0 | Blocking:
--------------------------+-------------------------------------------------

Comment(by raananc):

Replying to vaclavslavic:

I am trying to provide the same application on Windows, Linux & OSX, as
far as possible with the same source code. I tested your suggestion on
Windows (svn), and the lines

{{{

    locale = new wxLocale(wxLANGUAGE_DEFAULT, wxLOCALE_LOAD_DEFAULT );

    locale->AddCatalogLookupPathPrefix(applicationPath);
}}}
do not provide translation when the mo file is in
applicationPath/fr/translations.mo, even though
locale->[http://trac.wxwidgets.org/search?q=wiki%3AGetSystemLanguage
GetSystemLanguage]() gives 80 (French) as the current language.

So much for Windows.

Now for OSX: first question is what do you exactly consider as
applicationPath: the path to xyz.app or to xyz under MacOS?

I moved /fr/translation.mo from /MacOS to /Resources in the app package
and changed the source code to the two lines above.
locale->[http://trac.wxwidgets.org/search?q=wiki%3AGetSystemLanguage
GetSystemLanguage]() gives 80, but translation is not provided with 2.9.4.

As for locale->GetSystemLanguage(), the discussion over what gives the
user language in [http://trac.wxwidgets.org/ticket/15257 #15257] is too
unconclusive to actually put into code. Can you be more specific as to
what should be used?

By now I must admit that I am lost. While my code is maybe not terribly
standard, at least it provides the functionalities I need with Windows
(svn) and OSX (2.9.4).


--
Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:10>

[wxTrac]

Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:11>

#15253: No translation in osx trunk
--------------------------+-------------------------------------------------

Reporter: raananc | Owner: vaclavslavik
Type: defect | Status: accepted

Priority: normal | Milestone: 2.9.5
Component: translations | Version:
Keywords: | Blockedby:
Patch: 0 | Blocking:
--------------------------+-------------------------------------------------

Changes (by vaclavslavik):

* owner: => vaclavslavik
* status: new => accepted


Comment:

Replying to [comment:3 raananc]:

> The relevant code in my application is:

And what is the exact location (relative to `applicatoinPath`) of your
`gestioncomptes.mo` file?


--
Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:11>

[wxTrac]

Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:12>

#15253: No translation in osx trunk
--------------------------+-------------------------------------------------

Reporter: raananc | Owner: vaclavslavik
Type: defect | Status: accepted

Priority: normal | Milestone: 2.9.5
Component: translations | Version:
Keywords: | Blockedby:
Patch: 0 | Blocking:
--------------------------+-------------------------------------------------

Comment(by vaclavslavik):

Replying to [comment:10 raananc]:

> do not provide translation when the mo file is in
applicationPath/fr/translations.mo,

It's possible the bug fixed in r74253 caused this. In any case,
`AddCatalogLookupPathPrefix` looks into subdirs named after the language
(and is documented to), so there's really no point in add per-language
directory explicitly. You don't need to add `applicationPath/fr`, you only
need to add `applicationPath` -- and it works for ''all'' languages. This
is not specific to any platform.

> As for locale->GetSystemLanguage(), the discussion over what gives the
user language in [http://trac.wxwidgets.org/ticket/15257 #15257] is too
unconclusive

There's nothing inconclusive about it. You should never ever under any
circumstances use the default ''locale'' to set the UI ''language''.

> Can you be more specific as to what should be used?

Nothing. Use `wxLANGUAGE_DEFAULT` when initializing and that's it. Add
language-agnostic(!) paths with `AddCatalogLookupPathPrefix` if needed.

But this breakage should still be fixed, of course, I'll have a look.


--
Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:12>

[wxTrac]

Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:13>

#15253: No translation in osx trunk
--------------------------+-------------------------------------------------

Reporter: raananc | Owner: vaclavslavik
Type: defect | Status: accepted

Priority: normal | Milestone: 2.9.5
Component: translations | Version:
Keywords: | Blockedby:
Patch: 0 | Blocking:
--------------------------+-------------------------------------------------

Comment(by raananc):

Replying to [comment:11 vaclavslavik]:

Up to now it was in

gestioncomptes.app/Contents/MacOS/fr/gestioncomptes.mo

Looking at the implementation of DialogBlocks, language specific files are
stored in folders de_DE, and en_US. Theres folders are located next to the
executable: in Windows & Linux these folders are in the !DialogBlocks
folder; in OSX they are under MacOS folder (not in the Resources folder).

Is that where `AddCatalogLookupPathPrefix` looks for them? If the answer
is Yes, then I would modify my folders to suit this specification.

I would have appreciated if the wxWidgets documentation of
Internationalisation was more explicit on this point.

> Replying to [comment:3 raananc]:
> > The relevant code in my application is:
> And what is the exact location (relative to `applicatoinPath`) of your
`gestioncomptes.mo` file?

--
Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:13>

[wxTrac]

Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:14>

#15253: No translation in osx trunk
--------------------------+-------------------------------------------------

Reporter: raananc | Owner: vaclavslavik
Type: defect | Status: accepted

Priority: normal | Milestone: 2.9.5
Component: translations | Version:
Keywords: | Blockedby:
Patch: 0 | Blocking:
--------------------------+-------------------------------------------------

Comment(by raananc):

Replying to [comment:12 vaclavslavik]:

I do not use locale to set any language, as you can see from my code.

I need to know the currentLanguage (which I now get from
locale->GetSystemLanguage() or locale->GetLanguage() ) for my application.
If locale->[http://trac.wxwidgets.org/search?q=wiki%3AGetSystemLanguage
GetSystemLanguage]() is prohibited, is GetLanguage() any better ? If not,
then what else is available?

Replying to [comment:10 raananc]:

> > do not provide translation when the mo file is in
applicationPath/fr/translations.mo,
> It's possible the bug fixed in r74253 caused this. In any case,
`AddCatalogLookupPathPrefix` looks into subdirs named after the language
(and is documented to), so there's really no point in add per-language
directory explicitly. You don't need to add `applicationPath/fr`, you only
need to add `applicationPath` -- and it works for ''all'' languages. This
is not specific to any platform.
> > As for locale->GetSystemLanguage(), the discussion over what gives the
user language in [http://trac.wxwidgets.org/ticket/15257 #15257] is too
unconclusive
> There's nothing inconclusive about it. You should never ever under any
circumstances use the default ''locale'' to set the UI ''language''.
> > Can you be more specific as to what should be used?
> Nothing. Use `wxLANGUAGE_DEFAULT` when initializing and that's it. Add
language-agnostic(!) paths with `AddCatalogLookupPathPrefix` if needed.
But this breakage should still be fixed, of course, I'll have a look.

--
Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:14>

[wxTrac]

Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:15>

#15253: No translation in osx trunk
--------------------------+-------------------------------------------------

Reporter: raananc | Owner: vaclavslavik
Type: defect | Status: accepted

Priority: normal | Milestone: 2.9.5
Component: translations | Version:
Keywords: | Blockedby:
Patch: 0 | Blocking:
--------------------------+-------------------------------------------------

Comment(by vaclavslavik):

Replying to [comment:13 raananc]:

> Is that where `AddCatalogLookupPathPrefix` looks for them?

Err, this function ''adds'' path (and certain subpaths) to the list where
translations are searched for.

> I would have appreciated if the wxWidgets documentation of
Internationalisation was more explicit on this point.

Did you read `AddCatalogLookupPathPrefix` documentation? Because it is
very clear about what it does: ''Add a prefix to the catalog lookup path:
the message catalog files will be looked up under prefix/lang/LC_MESSAGES,
prefix/lang and prefix (in this order). This only applies to subsequent
invocations of wxTranslations::AddCatalog().'' (IOW, there's a reason why
it has "Prefix" in its name.) I'm sorry, but I really don't know how to
get the information through, I explained it above, the documentation
explains, the `internat` sample works like this.

> I do not use locale to set any language, as you can see from my code.

Actually, what I can see in your code is the exact opposite -- you ''do'':
{{{
currentLanguage = locale->GetSystemLanguage();

}}}

> I need to know the currentLanguage

I can't dispute that without knowing the rest of your code, but as I said
above, you most certainly do ''not'' need to know it in the code snippet
you posted.


--
Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:15>

[wxTrac]

Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:16>

#15253: No translation in osx trunk
--------------------------+-------------------------------------------------

Reporter: raananc | Owner: vaclavslavik
Type: defect | Status: accepted

Priority: normal | Milestone: 2.9.5
Component: translations | Version:
Keywords: | Blockedby:
Patch: 0 | Blocking:
--------------------------+-------------------------------------------------

Comment(by raananc):

We are talking about two differnet domains: you are concerned with the
system, I am concerned by the application. [[BR]]Consequently, we dont
seem to agree on what setting a language means: When I write
locale->GetSystemLanguage() I assume that locale did whatever it had to do
and by using
locale->[http://trac.wxwidgets.org/search?q=wiki%3AGetSystemLanguage
GetSystemLanguage]() the system tells me what it found. This is not
"setting a language" as far as I am concerned.

My code tries to ensure that the translation file actually used is not
corrupted by testing its length. For this I need to know which translation
file is used, i.e. which language.

Replying to [comment:15 vaclavslavik]:

> Replying to [comment:13 raananc]:
> > Is that where `AddCatalogLookupPathPrefix` looks for them?
> Err, this function ''adds'' path (and certain subpaths) to the list
where translations are searched for.
> > I would have appreciated if the wxWidgets documentation of
Internationalisation was more explicit on this point.
> Did you read `AddCatalogLookupPathPrefix` documentation? Because it is
very clear about what it does: ''Add a prefix to the catalog lookup path:
the message catalog files will be looked up under prefix/lang/LC_MESSAGES,
prefix/lang and prefix (in this order). This only applies to subsequent
invocations of wxTranslations::AddCatalog().'' (IOW, there's a reason why
it has "Prefix" in its name.) I'm sorry, but I really don't know how to
get the information through, I explained it above, the documentation
explains, the `internat` sample works like this.
> > I do not use locale to set any language, as you can see from my code.
> Actually, what I can see in your code is the exact opposite -- you
''do'': {{{ currentLanguage = locale->GetSystemLanguage(); }}}
> > I need to know the currentLanguage
> I can't dispute that without knowing the rest of your code, but as I
said above, you most certainly do ''not'' need to know it in the code
snippet you posted.


--

Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:16>

[wxTrac]

Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:17>

#15253: No translation in osx trunk
--------------------------+-------------------------------------------------

Reporter: raananc | Owner: vaclavslavik
Type: defect | Status: accepted

Priority: normal | Milestone: 2.9.5
Component: translations | Version:
Keywords: | Blockedby:
Patch: 0 | Blocking:
--------------------------+-------------------------------------------------

Comment(by vaclavslavik):

Replying to [comment:16 raananc]:

> When I write locale->GetSystemLanguage() I assume that locale did
whatever it had to do and by using
locale->[http://trac.wxwidgets.org/search?q=wiki%3AGetSystemLanguage
GetSystemLanguage]() the system tells me what it found.

Yes. It tells you the default ''locale'' -- '''NOT''' the default UI
language.

> This is not "setting a language" as far as I am concerned.

You use that information immediately afterwards to force use of UI
language -- how is that not setting a language?!

> For this I need to know which translation file is used, i.e. which
language.

See
http://docs.wxwidgets.org/trunk/classwx_translations.html#adb8979906e44477affb150f12c5f145c


--
Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:17>

[wxTrac]

Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:18>

#15253: No translation in osx trunk
--------------------------+-------------------------------------------------

Reporter: raananc | Owner: vaclavslavik
Type: defect | Status: accepted

Priority: normal | Milestone: 2.9.5
Component: translations | Version:
Keywords: | Blockedby:
Patch: 0 | Blocking:
--------------------------+-------------------------------------------------

Comment(by raananc):

I understand that the translation subject was (is) being reviewed, to
conform to OS evolution of using more than one language at a time
(internal & UI). wxWidgets 'internat' sample only shows how to use
wxLocale (translation.h is not even included in the sample.) You must bear
with me inasmuch as the new approach is not necessarily simple to
understand with so little explanation.

From the short description in wxTranslations it looks like there are two
competing/completing functions, inasmuch as wxTranslation can be used
without wxLocale, but earlier remarks seem to indicate that 
`AddCatalogLookupPathPrefix `is necessary.

Also, an explanation of the reason of the use of 'Best' in
GetBestTransaltion may help clarify what the class is trying to achieve.

It would be useful for users of wxWidgets to have a clearer view of how
transaltion is supposed to work in the new configuration, and which steps
are required to obtain a standard language setup.

Finally, if I am expected to use wxTranslations functions, I must at least
understand the meaning of the terms used: for example, the term 'Domain'
in [http://trac.wxwidgets.org/search?q=wiki%3AGetBestTransaltion
GetBestTransaltion.]



Replying to [comment:17 vaclavslavik]:

> Replying to [comment:16 raananc]:
> > When I write locale->GetSystemLanguage() I assume that locale did
whatever it had to do and by using
locale->[http://trac.wxwidgets.org/search?q=wiki%3AGetSystemLanguage
GetSystemLanguage]() the system tells me what it found.
> Yes. It tells you the default ''locale'' -- '''NOT''' the default UI
language.
> > This is not "setting a language" as far as I am concerned.
> You use that information immediately afterwards to force use of UI
language -- how is that not setting a language?!
> > For this I need to know which translation file is used, i.e. which
language.
> See
http://docs.wxwidgets.org/trunk/classwx_translations.html#adb8979906e44477affb150f12c5f145c


--

Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:18>

[wxTrac]

Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:19>

#15253: No translation in osx trunk
--------------------------+-------------------------------------------------

Reporter: raananc | Owner: vaclavslavik
Type: defect | Status: accepted

Priority: normal | Milestone: 2.9.5
Component: translations | Version:
Keywords: | Blockedby:
Patch: 0 | Blocking:
--------------------------+-------------------------------------------------

Comment(by raananc):

http://wxwidgets.info/wxtranslation/ is helpful.


--
Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:19>

[wxTrac]

Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:20>

#15253: No translation in osx trunk
--------------------------+-------------------------------------------------

Reporter: raananc | Owner: vaclavslavik
Type: defect | Status: accepted

Priority: normal | Milestone: 2.9.5
Component: translations | Version:
Keywords: | Blockedby:
Patch: 0 | Blocking:
--------------------------+-------------------------------------------------

Comment(by raananc):

If I understand correctly, there are two issues which have to be addressed
separately:

The first concerns the file structure for different platforms, the second
concerns the contents of these files.

Taking Microsoft Office14 as an illustration of how this is done in
'''Windows''', one can see the following structure:

C:\!ProgramData\Microsoft\OEMOffice14\Office14\ containing the folders
(sample): [[BR]]Access.de-de [[BR]]Access.en-us [[BR]]Access.fr-fr
[[BR]]Office.de-de [[BR]]Office.en-us [[BR]]Office.fr-fr [[BR]]Office64
.de-de [[BR]]Office64.en-us [[BR]]Office64.fr-fr

Each of the language folders contains a set of files specific to each
software component (Access, Office, Office64)

[[BR]]In '''OSX '''(10.4 and later), an application package contains, in
the Resources folder, language-specific folders such as

German.lproj

English.lproj

French.lproj

I have no knowledge about how language is managed in '''Linux'''.

Each platform is using its own technology for transaltions.

From this short analysis, can one draw the following conclusions about
what wxTranslations is expecting?

1. The location of the language folders in Windows & Linux is specified
by `AddCatalogLookupPathPrefix.`In OSX, there is no need to call
`AddCatalogLookupPathPrefix `if the language folders are in the
'Resources' folder of the '.app' folder.[[BR]](If there is no other use
for wxLocale than specifying the catalog lookup path prefix, then maybe
this function can be transferred to wxTranslations which would than be
self-sufficient).[[BR]]
1. In Windows & Linux, language folders are named following the
'ApplicationName.fr-fr' convention[[BR]]In OSX, language folders are named
following the 'Language.lproj'
convention.[[BR]][http://trac.wxwidgets.org/search?q=wiki%3AGetBestTransaltion
In Windows, GetBestTransaltion] takes [wiki:ApplicationName
"'ApplicationName"]' as the 'Domain' argument. If the folders are named as
fr-fr, then 'Domain' argument should be a wxEmptyString ?[[BR]]
1. The language folders contain .mo files


--
Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:20>

[wxTrac]

Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:21>

#15253: No translation in osx trunk
--------------------------+-------------------------------------------------

Reporter: raananc | Owner: vaclavslavik
Type: defect | Status: accepted

Priority: normal | Milestone: 2.9.5
Component: translations | Version:
Keywords: | Blockedby:
Patch: 0 | Blocking:
--------------------------+-------------------------------------------------

Comment(by vadz):

Unfortunately I don't have time to dive into this discussion right now, I
hope Vaclav can take some decision about this. And if we could solve
#12498 too, it would be even better.


--
Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:21>

[wxTrac]

Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:22>

#15253: No translation in osx trunk
--------------------------+-------------------------------------------------

Reporter: raananc | Owner: vaclavslavik
Type: defect | Status: accepted

Priority: normal | Milestone: 2.9.5
Component: translations | Version:
Keywords: | Blockedby:
Patch: 0 | Blocking:
--------------------------+-------------------------------------------------

Comment(by vaclavslavik):

Replying to [comment:20 raananc]:

> I must at least understand the meaning of the terms used: for example,

the term 'Domain' in GetBestTransaltion.

The documentation does explain it (see AddCatalog). It also points you to
the GNU gettext manual, in addition to saying that gettext is what we use.
I can't recommend it enough, it explains the fundamentals of gettext very
well.

> 1. In Windows & Linux, language folders are named following the
'ApplicationName.fr-fr' convention

Not really. The Unix convention is exactly what wx expects and uses (and
what is documented in AddCatalogLookupPathPrefix). There's no convention
to speak of on Windows -- and wx expects the documented layout there too.

> q=wiki%3AGetBestTransaltion In Windows, GetBestTransaltion] takes
[wiki:ApplicationName "'ApplicationName"]' as the 'Domain' argument. If
the folders are named as fr-fr, then 'Domain' argument should be a
wxEmptyString ?[[BR]]

No. See above, domain = catalog name and should never be empty.

You should just use the standard, documented layout: i.e. putting catalogs
into directories named after languages (e.g. fr/foo.mo) and pointing
AddCatalogLookupPathPrefix to the directory under which the per-language
dirs are. See the "internat" sample, it shows all this in action.

Contrary to what I wrote in comment:12, your usage would be pretty hard to
support in 2.9 (because of GetAvailableLanguages) and is something that
doesn't really make much sense to support -- it cannot possibly support
multiple languages, which is the whole point of wxLocale/wxTranslations. I
will update the documentation accordingly.


--
Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:22>

[wxTrac]

Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:23>

#15253: No translation in osx trunk
--------------------------+-------------------------------------------------

Reporter: raananc | Owner: vaclavslavik
Type: defect | Status: accepted

Priority: normal | Milestone: 2.9.5
Component: translations | Version:
Keywords: | Blockedby:
Patch: 0 | Blocking:
--------------------------+-------------------------------------------------

Comment(by VS):

(In [74441]) Don't look for catalogs in AddCatalogLookupPathPrefix() path
directly.

Previously, the prefix directory itself for searched for catalogs, in
addition to prefix/lang/LC_MESSAGES and prefix/lang. This never made
much sense, because only one catalog could be in such place, instead of
multiple catalogs for more languages. It also prevented successful
identification of catalog's language and didn't work with
GetAvailableLanguages().

Remove this misfeature and update the documentation accordingly. Update
OS X-specific code so that it continues to work (it previously depended
on this behavior). As a side effect, *.lproj directories are now
recognized in all search prefixes, not just in Resources.

See #12498, #15253.


--
Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:23>

[wxTrac]

Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:24>

#15253: No translation in osx trunk

---------------------------+------------------------------------------------
Reporter: raananc | Owner: vaclavslavik
Type: defect | Status: closed

Priority: normal | Milestone: 2.9.5
Component: translations | Version:

Resolution: fixed | Keywords:
Blockedby: | Patch: 0
Blocking: |
---------------------------+------------------------------------------------
Changes (by VS):

* status: accepted => closed
* resolution: => fixed


Comment:

(In [74442]) Clarify .mo deployment in i18n overview.

Fixes #15253.


--
Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:24>

[wxTrac]

Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:25>

#15253: No translation in osx trunk

---------------------------+------------------------------------------------
Reporter: raananc | Owner: vaclavslavik
Type: defect | Status: closed

Priority: normal | Milestone: 2.9.5
Component: translations | Version:

Resolution: fixed | Keywords:
Blockedby: | Patch: 0
Blocking: |
---------------------------+------------------------------------------------

Comment(by raananc):

Thanks for the much clearer documentation. There remains an unexplained
issue: the link between wxLocale and wxTranslations.

From the wxLocale documentation it looks like wxLocale would be enough.
Part of the discussion here was due to that notion: "For a list of the
supported languages, please see wxLanguage enum values. These constants
may be used to specify the language in wxLocale::Init and are returned by
wxLocale::GetSystemLanguage." (wxLocale documentation). However,
GetSystemLanguage is no more appropriate for user interface, so some
wording is necessary in wxLocale to that effect.


--
Ticket URL: <http://trac.wxwidgets.org/ticket/15253#comment:25>