I'm looking for a way to localize SharePoint 2010 Folder Names, for a specific application.
I've seen that site names/description are automatically translated, and it seems like SharePoint 2010 supports "multilingual" fields for metadata - but I haven't been able to apply this successfully for folder names.
The folders are automatically generated, and the number of folder is limited (so I'm not looking at providing the users a way to translate their folder names, but a way to localize a predefined folder structure).
In a nutshell :
- is there a way to localize folder names ?
- if yes, is what's the best way to deploy this as part of a solution ?
Have you considered how Managed Metadata might be able to help you with this? If you're able to control terms that are also localized in Taxonomy, perhaps when creating a folder you would pull from the Managed Metadata Store, and then display the appropriate language based on the user's language setting. Just a thought... Since you know the name of the folder ahead of time, you could use that as a label for a folder name term, and then pull another label that matches the user's language and display that.
You can start using a resource files in your project and this link can help you about it.
But if you want to let the user, who creates a folder to set its localized name; then you should consider using SP event receivers.
I hope I've understood you correctly.
Related
I'd like to set up metadata in a document library so that it's only applicable to folders (and subfolders). Meaning that when we add documents they shouldn't get the metadata from the columns on the folders.
I am not experienced in Sharepoint, but I tried with lists and played around with a new document library but had no success.
I thought maybe DocumentSets may help but it seems I don't have enough privileges to create them (if that's really the solution here).
Any help would be greatly appreciated.
You can create a custom Folder content type(called CustomeFolder in my test), and add site columns based on your requirement.
Then go to the library that you want to use, enable content type management, and add the custom folder content type into your library.
After that, click "customFolder" to create a folder/subfolder with metadata:
How to create a custom content type:
https://support.microsoft.com/en-us/office/create-or-customize-a-site-content-type-27eb6551-9867-4201-a819-620c5658a60f
How to add a content type into a library:
https://support.microsoft.com/en-us/office/add-a-content-type-to-a-list-or-library-917366ae-f7a2-47ad-87a5-9689a1884e60
Note: To create a custom content type, you need to have site owner permission.
Document Set also is a choice, but to create a document set, you need to be a site collection administrator.
Create and Configure a new Document set:
https://support.microsoft.com/en-us/office/create-and-configure-a-new-document-set-content-type-9db6d6dc-c23a-4dcd-a359-3e4bbbc47fc1
https://www.c-sharpcorner.com/article/create-a-document-set-in-sharepoint-online-office-365/
I'm completely new to Sharepoint so keep that in mind when answering or assuming things.
Anyways, we have a CRM 2015 Online Update 1 and Sharepoint Online and those are integrated (not by me). Now when an end-user goes to Account -> Documents the CRM will automatically ask if the user wants to create a folder to Sharepoint. That's fine, but naming convention seems to be "AccountName_AccountGuid". We would like to change that to "AccountName_OurOwnID" where OurOwnID is a custom field in CRM that is unique for every account.
So my question is how would one do this?
EDIT: All I can think of now is to create a plugin that'll be launched when ever a sharepointdocumentlocation entity is created and basically create a new folder with wanted name and then delete the original folder in Sharepoint and then connect the new folder with sharepointdocumentlocation.
Sub-question: Is there a way to tell CRM to stop asking if the user wants to create a new folder? In my case it's unwanted feature but since it is there at least we should make sure that names of the folders will be ok.
The folder name with the guid is default behavior which cannot be altered.
If you want to develop a plugin, look at this post: https://crmconsultancy.wordpress.com/2011/10/27/crm-2011-integration-with-sharepoint-custom-document-management/
Keep in mind, if you want to create objects in SharePoint from CRM online you have two options:
Add the SharePoint.Client assembly with ILMerge. Officialy this is not supported.
Or use the rest endpoint of SharePoint. This is an interesting post to read: https://bingsoft.wordpress.com/2013/06/19/crm-online-to-sharepoint-online-integration-using-rest-and-adfs/
I am beginning sharepoint development and have some quick questions concerning basic terms.
How do i find out whether a particular site is a site collection, or a site JUST BY THE URL? Is their a powershell command to do this?
I was creating some sites in sharepoint. Some sites were appended with /sites/sitename whereas others were just under the base url of sharepoint. What is the difference between the 2? AND, how do i recreate the ones under the sites node? For some reason, I cant find the option to create under the sites node again. Please explain this concept as all msdn tutorial are very confusion for beginners like me. Those are good once you get the hang of basics.
Please provide an analogy how to understand web app, site collection, site, web site, etc.
Is there a way to use NEWFORM.aspx for a document library instead of UPLOAD.aspx?
The Site collection is at the root level of your Web application.
So http://abc.com/ => Site collection
Using Powershell, open the Sharepoint Powershell prompt and run Get-SPSite to get all Site-Collections
the /sites/ is called as a managed path
It can be defined in the Central Administration for every web application.
The option to select the /sites will be available only when you create the second site collection under the Web Application (The first one take the / by default.)
Have a look at Technet Article
document library is for uploading file, not for storing user submitted data, for that you need to create a list
1) Document Set is used in cases where multiple documents have the same properties, its like putting all these documents in a folder and then providing attributes to that folder which are in turn applied for each document in that folder.
In your case, if all the files have the same values for the 8 fields then the document set is the correct way to go.
2)If there is additional metadata associated with the files then these can be added either to the content type (eg. document or document set content type) or to the columns in the library itself, you dont need to create a separate list for holding that data. Adding data to the content type ensures consistency across all the document libraries within that site collection, adding columns to the library affects only that library.
I have a requirement wherein I have to obtain all the files of a web recursively (i.e. traversing through the folders and sub folders) and display them for the user through SP Object Model.
This has to be security trimmed, in the sense, if the user doesn't have sufficient privileges to view or open the file, then that file shouldn't be taken into account. Is it possible to obtain all the files without looping through each and every document library, folders and sub folders?
Also, I don't want the default document libraries like web part gallery, master page gallery,etc to be listed out. Any insights on how to achieve this?
The Content Query Web Part can get you most of the way there. Out-of-the-box you could set this up to show all files (based on a content type or content type category) from a site collection. You could even filter to remove system files although that might be a little tricky to get the filters right.
If that doesn't get you far enough, then you could write a web part that extends the Microsoft.SharePoint.Publishing.WebControls.ContentByQueryWebPart class. You could override the Filters (by setting the FilterField1, FilterType1, FilterOperator1, FilterValue1, etc).
The security trimming should happen for you by the default behavior of the ContentQueryWebPart. The Web Part and Master Page galleries will get filtered out based on your content type settings so you shouldn't have to worry about those.
To quickly summarise my question:
Is it feasible to programmatically change the name of a directory (with both files and sub-folders) in SharePoint? I am expecting that users will have files checked out on at least some occasions what I am attempting the rename.
The background:
I am currently contracting for a company that produces web based software (ASP.NET) with a configurable document management system. The system can be configured to use different underlying systems, with the most common environment being SharePoint (WSS 3).
I have been assigned a task to extend what has to now been a fairly simple system (simply output files into a fixed directory structure, occasionally read). Having never worked with SharePoint before I am doing some research on best practices, and am attempting to work out what is viable. At this stage I do not have access to a testing environment myself, so am limited to reading up online.
One request is to have the directory structure reflect the name (as one example) of the current client - so all documentation for a client will be in one place, and can be accessed externally via SharePoint or other compatible applications. The specification cites that if the name of the client changes then the directory structure should immediately update. My concern is that this will either directly cause errors (eg. Permission denied) or indirectly cause errors (loss of work for users who have externally checked out files).
As a follow up question if there are concerns with the above, is there a better way to implement the above? I have looked at suggesting the users use views to access the structure in SharePoint, however there is a concern from our BA that users will not be able to directly upload new files into this structure.
Thanks
The issue with Folders in SharePoint is that they are not really folders in the way you would expect of a file system. All files in a SiteCollection are stored in one big-assed table on the Database (checkout the AllDocs table).
I cannot categorically say it is safe to rename the folder without doing a bit of testing, I know that the folders "name" is not the key to accessing the document, despite it appearing to be based on the Url you see in the browser.
The best bet is to do a quick test, but I am pretty sure that your plan will not be a problem.
The potential issue is if any Content Query Web Parts etc rely on specific folders to exist or if any other "code" or "pages" look for that folder and not the folderId.
Save the content of the list before you "attempt" it in production. You don't want to loose data.
Checked out documents will still work the way you expect them to.
You may however have to run a crawl again.