Regression: Folder names are no longer translated

[taos]

Using hrev43255 (gcc2hybrid).

Although translation of folder and application name is enabled in locale preferences, now only the application names are translated, the folder names stay un-localized (see e.g. the deskbar menu.)

BTW, in an un-localized system the home folder is now written with a capital letter: "Home", the German localization used to have "Benutzer" but is at the moment back to "home" with a lower case letter.

[taos]

Deskbar menu (German localizaion).

[jscipione]

Relevant ML discussion: ​http://www.freelists.org/post/haiku-development/Localization-of-file-names

Results inconclusive. But you can read what has been said on the subject yourself.

[taos]

Replying to jscipione:

Relevant ML discussion: ​http://www.freelists.org/post/haiku-development/Localization-of-file-names

Okay, this discussion is from 2010 - however, alpha 3 and a number of post-alpha 3 revisions (I guess until late october or early november) did translate both application and selected folder names such as "config", "home", "applications", "preferences", etc. It's only recently that folder names are no longer translated. So, I still think it's a regression.

[taos]

For comparison: Deskbar menu in alpha 3 (German localization).

[taos]

Short excerpt from syslog that shows a number of folders which can't use localization due to lack of mimesignature.

[jscipione]

I dug through the source and it might be generating catalog entries for those items on release builds only. Try running

/Haiku/common/boot/post_install/add_catalog_entry_attributes.sh

and see if that gives you the mime signatures for those folders. That script seems to generate the catalog entries in Deskbar, Tracker, Mail, and some other places.

It may or may not localize the name depending on if the entries were removed from the catalog files of your locale between alpha3 and now.

[taos]

Replying to jscipione:

/Haiku/common/boot/post_install/add_catalog_entry_attributes.sh

I had already tried that before I opened the ticket.

I don't think that these entries were removed from the catalog files - they're still part of tracker kit on HTA.

The last revision with translated folder names that I used was hrev42804, the first without translated folder names was hrev43203. That's almost 400 changesets - so not really helpful.

[humdinger]

I narrowed it down by testing various nightlies. The responsible commit has to be between hrev43006 and hrev43034. Possible candidates may be hrev43029, hrev43022, or hrev43018.

[taos]

I've done a little compiling and testing:

hrev43029: only application names are translated
hrev43022: only application names are translated
hrev43018: application and folder names are translated

So, hrev43022 might be the culprit.

[anevilyak]

The culprit is hrev43021. Attaching a possible fix.

[jonas.kirilla]

I don't think the patch is right. Translations of filenames can live in any catalog, anywhere, not limited to the catalogs related to Tracker. (The Deskbar menu folders translations live in Deskbars catalog. And, for example, a pkgfs package could have its folders translated, providing its own catalog for this. As long as the system knows how to look up a catalog by its signature.)

The lookup happens like this:

A filesystem entry has an attribute called SYS:NAME with the contents (catalog signature : context : string). If the Locale setting "Translate apps and folders in Deskbar and Tracker" is selected, Tracker will attempt to use the BLocaleRoster to look up translations.

Tracker calls BLocaleRoster::GetLocalizedFileName(BString& localizedFileName, const entry_ref& ref, bool traverse) with the entry_ref of the filesystem entry (file, app, folder or link) to see if there's a translation for it.

Which in turn calls the method _PrepareCatalogEntry() which simpy reads the SYS:NAME attribute of the entry and parses its contents as three string: catalog signature, context and string.

The signature is (or, rather, was) used to find the proper catalog, in which to look up the translation of string/context, but it seems the method BCatalog::SetCatalog(const char* signature, uint32 fingerprint) was removed.

So, how to find the right catalog for an arbitrary signature, post hrev43021?

[pulkomandy]

It is not possible to load a catalog by signature only. It was removed because it doesn't work with catalog embedded as resources/attributes, neither with catalogs put in a "locale/catalogs" folder next to the application.

So, a catalog is now identified by an entry_ref pointing to a file. The default catalog implementation happens to use that file mime signature amongst other things. A gettext catalog implementation would likely do otherwise.

The idea for this feature is :

• Try to load a catalog for the given entry_ref. This will work for applications
• If it doesn't work, use libtracker. This will work for a given static list of well known folder names.
• You can't translate anything else.

Does that miss some other cases ? I don't think we want localized datafiles names ?

The patch is not correct anyway, because the change actually has to occur in _PrepareCatalogEntry:

• remove the signature arg.
• fail if the ref doesn't have an embedded catalog
• allow to look for a ref translation in libtracker, if the ref doesn't have a catalog by itself.

[bonefish]

Replying to pulkomandy:

It is not possible to load a catalog by signature only. It was removed because it doesn't work with catalog embedded as resources/attributes, neither with catalogs put in a "locale/catalogs" folder next to the application.

I don't quite see why. The application's executable can be found by signature and consequently its locale/catalogs directory can be found as well. I don't know the purpose of the resources/attributes embedded catalogs. Assuming that it's just another obscure format supported by some catalog add-on, I'd just disallow all but the default format for translating file names.

The idea for this feature is :

• Try to load a catalog for the given entry_ref. This will work for applications
• If it doesn't work, use libtracker. This will work for a given static list of well known folder names.
• You can't translate anything else.

Does that miss some other cases ? I don't think we want localized datafiles names ?

This essentially makes it impossible to localize the names of any files or directories that don't already come with the system (except application files). E.g. if an office suite comes with clip art, the names of those files and the names of the directories the files are organized in could not be translated. The same goes for any kind of sample or support data directly accessed by the user via Tracker or a file panel.

[pulkomandy]

You can query a file by mimesignature and load a catalog from there, it would work as well. There is a bit of uncertainity on what you get if both of these are true:

1) There are multiple instances of the application installed 2) One of them use resources or a local folder for catalogs.

I expect 3rd party apps to use either a local folder or resources for their catalogs, as we like self-contained apps. And, these apps are the ones that would benefit from a more flexible system for example in the case you mention. I'm not sure it's a good idea to go that way. For example, you'd need to query these ckliparts by their original name, because the translated one is stored in a catalog and not in the filesystem. This makes the feature a lot less interesting.

[jstressman]

Just noting that I have this same problem in hrev43789 still. Spent a bit of time comparing nightlies to Alpha3 (which works as expected) under different languages etc only to find in the end that this bug was already filed.

[leavengood]

Since this is an alpha4 blocker, I'm taking a look. I already have a fix, but I'm finding some other bugs I'd like to fix related to it.

[leavengood]

Should be fixed in hrev44563, along with a few other related problems.