localized files

[skurfer]

If a file object also happens to be the root of a catalog entry, use the catalog entry's name instead of the file's name? Ummm… How about "no". :-)

This was causing things like ~/Desktop and ~/Downloads to appear in English no matter what.

[pjrobertson]

Shouldn't we just localise the catalog entry (preset, I'm assuming) names?

I know people do this: http://blog.qsapp.com/post/16872009699/creating-custom-catalog-entries-to-rename-items

OK, they can still do this by adding the actual catalog entries to the catalog, but is this enough? Probably

[skurfer]

Shouldn't we just localise the catalog entry (preset, I'm assuming) names?

Yes, probably.

OK, they can still do this by adding the actual catalog entries to the catalog, but is this enough? Probably

The screenshot in the blog entry shows “Sparrow Mail (Catalog)”, but that must be a mistake, because you can’t run the Open action on that, which is sort of the point. So I don’t think catalog entries would get the job done (unless maybe you right-arrow into them). So, this change breaks the technique shown in that post. But having a catalog entry name override the name of a file object (in all contexts) seems like a bug to me.

The desire to assign an abbreviation that isn’t part of the name/label is a common one, but it should be addressed separately, I think.

[pjrobertson]

I still don't agree with you on this one… I think the whole point of being to set an entry's name is so that you can override the default.

BTW most of the code you've deleted never gets called anyway, which is fine.

OK, I agree that localised names shouldn't be changed to English, but I think we should fix this as follows:

        NSString *name = [theEntry objectForKey:kItemName];
        NSString *theID = [theEntry objectForKey:kItemID];
        if ([theID hasPrefix:@"QSPreset"]) {
            NSString *presetName = [[NSBundle mainBundle] safeLocalizedStringForKey:theID value:theID table:@"QSCatalogPreset.name"];
            if ([presetName isEqualToString:name]) {
                name = nil;
            }
        }
        if (name) [mainObject setLabel:name];

What this does is use the name entered in the Catalog prefs unless it is the same as the default (unlocalised) string, in which case it does what your code does - nothing.
But if you've changed the name in the catalog prefs for whatever reason, it uses that

[skurfer]

I think the whole point of being to set an entry's name is so that you can override the default.

I have no problems with what you're saying about the names of catalog entries. This change was about the names of file objects. For instance, on a Swedish system, the name of ~/Documents would be correctly set to "Dokument", but then this code would come along behind it and change the file object's name to "Documents", just because there was a catalog entry with the same path. Names of catalog entries and files should have nothing to do with each other, right? If anything, we should go the other direction and let the file name override the entry name. That would solve our localization problems. :-) But I agree that you should be able to customize entry names, which basically requires them to be set independently.

I also agree that users should have some way to assign alternate names to objects, but renaming catalog entries seems like a hack and it doesn't even work for the general case. It only works for files and folders.

This is a larger discussion not really related to this pull request, but I think the best way to solve that would be to add a new "Proxy Object" catalog entry type. Basically, you'd create a new custom entry, a QSSearchObjectView would come up for you to select a real object from the catalog, you give it a name, and a "static" proxy object gets added to the catalog with that name.

That would let people refer to Colloquy as "IRC Client", but it would also apply to other things. You could create your own proxies for "Favorite Album", "Wife", etc.

[pjrobertson]

Just copied from IRC:

I still think we should keep in the ability to change names using catalog entries.
…since I wrote that blog post
what I have suggested won't break anything for existing users (who might have custom catalog names set up), but will get the localisation working properly for everybody else. Win win

Maybe when the fancy proxy object catalog type is created, we can disable this all together as you've suggested. Fancy including that in the pull? :P

[skurfer]

The problem I have is with the way the catalog entry name bleeds into contexts where it doesn't belong. For example

1. You have a folder ~/Projects
2. You add a custom catalog entry for it named "Code and other stuff"
3. Select ~ in the first pane
4. Hit / or →

What do you expect to see? I would expect to see a list of files (i.e. "Projects"), not catalog entries (i.e. "Code and other stuff"). If we don't agree on that, then maybe we should get someone else to weigh in.

Maybe when the fancy proxy object catalog type is created, we can disable this all together as you've suggested. Fancy including that in the pull? :P

Before you even brought it up, I was going to say "If I have to implement the new object source right here in this pull request, I will!" ;-)

[hmelman]

I don't follow all the details, but yes, typing ~ followed by / should show a list of files (only).

[hmelman]

Ok, I follow more of it now and agree (I think completely) with skurfer. Catalog entries are not their contents. We've lived with not being able to have an abbrev of IRC for Colloquy for a long time now, we can survive until there's a real fix, not a hack that breaks something else. If there's a real localization issue I'd be more willing to accept a quick fix (though in general I ususally hate quick fixes). The static proxy solution seems better or making it so a filesystem solution (a symlink or alias perhaps) actually works would better too.

[hmelman]

Ok, I follow more of it now and agree (I think completely) with skurfer. Catalog entries are not their contents. We've lived with not being able to have an abbrev of IRC for Colloquy for a long time now, we can survive until there's a real fix, not a hack that breaks something else. If there's a real localization issue I'd be more willing to accept a quick fix (though in general I ususally hate quick fixes). The static proxy solution seems better or making it so a filesystem solution (a symlink or alias perhaps) actually works would better too.

[skurfer]

I've got user-defined proxies working. :-)

Not sure where this is going to end up, so I've got it in its own branch for now. Here's the diff vs. master. I'd appreciate it if you could give me some advice on getting the NIB set up correctly. I just want a way to search the catalog for a single object (with a results list). I'm sure you will figure it out if you just open the new NIB.

To see it in action, manually add a custom entry like this to your Catalog.plist:

<dict>
    <key>ID</key>
    <string>1A7359E7-B59E-430D-B1C7-BFDCFB6A81CA</string>
    <key>enabled</key>
    <true/>
    <key>name</key>
    <string>IRC Client → Colloquy</string>
    <key>settings</key>
    <dict>
        <key>name</key>
        <string>IRC Client</string>
        <key>target</key>
        <string>/Applications/Colloquy.app</string>
    </dict>
    <key>source</key>
    <string>QSUserDefinedProxySource</string>
</dict>

Other things:

• Eventually, I envision having an action too, similar to "Assign Abbreviation…".
• You probably won't see an icon for these proxy objects. That's fixed in resolve direct object before using it to determine indirects #1248, so create a new garbage branch, merge both synonyms and validIndirects into it, et voila… icons!

[pjrobertson]

Had a quick look over your branch. Yes, it seems that you do need a QSInterfaceController (and a window) for a QSSearchObjectView. Look in QSObjectView and QSSearchObjectView and see how many calls there are to self window.

Probably why the command builder was built. A bit of a pain :(

[skurfer]

Yes, it seems that you do need a QSInterfaceController (and a window) for a QSSearchObjectView.

That's what I was afraid of. Thanks.

[pjrobertson]

@skurfer - how's the synonyms branch looking? Is it likely it'll be finished anytime soon? i.e. should this be merged...?

I'm semi-happy, but think we should add the new feature at the same time as taking the old feature (bug) away (the one here).

[skurfer]

how's the synonyms branch looking?

Complete …or ready for a pull request anyway. I'm assuming there will be suggestions and visual tweaks once others get a look at it. The only reason I haven't done one is that it really works better with the proxy object clean-up that only exists in release at the moment. The commits are pretty messy, too. So I was waiting for release to get merged into master, then I was going to rebase all my work on that.

I've pushed it all to my fork though, if you want to take a look. (I think the only thing really fixed by the release branch is the icon.)

[pjrobertson]

Coooool, I like the popup! :)
It might be a little big, but I'm fine with it.

A couple of things from some quick tests:

• The name of the catalog entry is > "Object Name". Should it be Synonym > "Object Name"? (And it seems to take a while to update. Perhaps a catalog rescan?)
• The list should somehow exclude synonyms. I created a synonym, saved it, then edited the 'target name' and selected the synonym itself, creating a circular relationship. After restarting it turned into a plain old 'proxy object'
• Maybe add some documentation to the sidebar?

Other than those small things, it all seems good.
I'll merge this into master since I don't expect it'll be long before we see that one in master :)

[skurfer]

I'll merge this into master since I don't expect it'll be long before we see that one in master :)

Yeah, hopefully we can get a release going soon. I'll save my comments on synonyms for when it has a pull request to go with it.