Forum .LRN Q&A: Is localized cr_items.name necessary for file-storage?

In the file-storage applet for .LRN, several "built-in" folders are created such as assignments, syllabus, etc.

Currently a localized message key is stored in cr_folders.label and cr_items.name and is localized when it is used. This works great for cr_folders.label which is used for the web user interface display of the folder name.

It breaks browsing of the folders with the view feature, and new webdav support that uses the cr_items.name to resolve the URL because the folder URL looks like "<span>#</span>file-storage.Assignments#".

My idea is to localize the string before the folder is created for the name to the default locale of the openacs install. The folder label used to the display would still be shown in the users preferred locale.

I think it is not necessary to distinguish between user's view and system view. If on a German site a folder "Öffentliche Dateien of X" is created, a US guest switching his locale back to English will understand this and need not see "X's Public Files". He might even be confused seeing something else than his neighbor.

Dave,
perhaps I do not even understand your question properly. File and class names do occur in nested localized messages, for instance, "Are you sure you want do delete #public-folder# and all of its content?" or the like. Names should remain constant, whereas the surrounding parts of the messages should be localized. But that's only my user's preference and I don't know about the intended design, as I said already here https://openacs.org/forums/message-view?message_id=167301

I want to clarify that the display name (cr_folders.label) has no consequence on the code I am writing for WebDAV support or on the /view/ feature URLs.

My original point is that the URL can change based on a users locale, which makes it difficult to write an application based on the URLs becuase currently the strings are not localized before the URL is resolved so we end up with something like /file-storage/<span>#</span>file-storage.Assignments# which is not a valid URL.

"Ola, URLs with # shouldn't work. That is supposed to be the fragment identifier. Maybe the browser is luckily urlencoding it for you."

Dave, the browser wasn't luckily urlencoding the URL - I added code which does this explicitly before the href is rendered. See: http://cvs.openacs.org/cvs/openacs-4/packages/file-storage/www/folder-chunk.tcl?r1=1.15.2.3&r2=1.15.2.4

By default, "ns_conn url" and friends will decode the encoded hashes back into the original shape so that the returned paths, path fragments, or whatever will properly match strings with localizable keys fetched from the db. If the href is NOT urlencoded beforehand, though, the URL shown in the browser's address field will still contain ENCODED hashes, but - in the "view" index.vuh, for instance - "ns_conn url" will choke on the first hash and cut the URL right there ...

As for the validity of the URL: /file-storage/<span>#</span>file-storage.Assignments# is apparently not a valid URL, but /file-storage/%23file-storage.Assignments%23 is - or so it seems.

/Ola

Yeah, I agree.

Notice that I used a regexp to encode the "#". That was because neither ns_urlencode nor ad_urlencode did this ... (Note to self; might this be a subtle indication as to not incude #'s in URLs? 😉

Anyway, I have no strong opinion how this is revamped - but wouldn't it make most sense to simply never apply localization on the name (I'm not talking about the label where I do think it makes great sense)? That is, skip the key altogether.

/Ola

Ola,

I did a split $uri "/" and urlencoded each part, then joined it back together.

It appears that MS WebFolders clients still connect handle the URLs even if they are urlencoded, so the best bet is going to be to take out the message keys and use the system locale for the folder URLs.