+
SharePoint Tip - Localizzazione all’interno di una feature
Pubblicato il: 19/03/2010
Da: Giuseppe Marchi
Lingua: Italiano
Livello: 300

L’intera piattaforma di provisioning offerta da Windows SharePoint Services 3.0 contiene dei meccanismi di localizzazione di base da poter utilizzare all’interno delle proprie personalizzazioni (web part, feature, pagine, ecc …), tutti “ereditati” dal motore di localizzazione di ASP.NET 2. Questo per supportare la presenza di uno o più Language Pack che possono essere aggiunti all’installazione di base, e per permettere ai nostri oggetti custom di “presentarsi” nella maniera più consona possibile all’interno di siti SharePoint creati con lingue differenti.
Per una feature questi concetti sono molto importanti in quanto, per definizione, una feature è un contenitore di personalizzazioni che può essere attivato in contesti (siti SharePoint) differenti e che quindi deve essere costruito a priori, cercando di astrarsi dalla struttura del sito all’interno del quale poi verrà utilizzata. Perciò cercando di rispettare questi concetti, titolo e descrizione di qualunque feature ad esempio, dovrebbero essere distribuiti per la maggior parte di lingue possibili, in quanto la feature in questione potrebbe essere attivata all’interno di un sito SharePoint creato con una lingua differente da quella su cui si è basato lo sviluppatore, da quella propria del server o da quella dell’installazione base del prodotto di collaborazione.
Per localizzare il contenuto di una feature, abbiamo due differenti metodi da seguire:

1.       utilizzare uno o più file di risorse posti in un contesto condiviso,

2.       utilizzare uno o più file di risorse, propri per la singola feature.

La prima opzione vede la presenza dei file di risorse (.resx) posti all’interno della directory:

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\Resources

Ognuno di questi file deve rispettare la sintassi <nome>.<cultura>.resx, per permettere al motore di provisioning di SharePoint di “pescare” il file giusto a seconda della lingua con cui è stato creato il sito all’interno del quale viene attivata la nostra feature.
All’interno della feature stessa, questi file di risorse vengono richiamati tramite l’attributo DefaultResourceFile che deve essere valorizzato con il nome su cui si basano tutti i file .resx; così facendo abbiamo la possibilità di recuperare i singoli valori, attraverso le rispettive chiavi, utilizzando questa sintassi:

$Resources:<nome_file_risorse>,<chiave>;

Quindi, salvando all’interno del percorso condiviso i nostri file di risorse SharePointCommunity.resx, SharePointCommunity.it-it.resx e SharePointCommunity.en-US.resx, possiamo localizzare titolo e descrizione della nostra feature in questo modo:

<?xml version="1.0" encoding="utf-8"?>

<Feature Id="603c8932-7af7-45d0-a8f2-3fe16c5a56b7"

    Title="$Resources:SharePointCommunity,FeatureTitle;"

    Description="$Resources:SharePointCommunity,FeatureDesc;"

    Version="1.0.0.0"

    Scope="Site"

    Hidden="FALSE"

    DefaultResourceFile="SharePointCommunity"

    xmlns="http://schemas.microsoft.com/sharepoint/">   

</Feature>

L’utilizzo di questo primo metodo risulta ottimo nel caso in cui vogliamo unire tutti i valori di localizzazione propri di varie feature, all’interno di un unico contenitore.

Nota: è considerata una best practice, quella di creare un file di risorse “neutro” (quindi senza una cultura definita) per fare in modo che la nostra personalizzazione si presenti in maniera adeguata anche se viene installata ed attivata all’interno di un sito SharePoint creato con una lingua che non è tra quelle che abbiamo previsto in fase di sviluppo della nostra feature.

Il secondo metodo invece, prevede la presenza di una directory denominata “Resources” all’interno della directory rappresentante la nostra feature, contenente tutti i file di risorse per ognuna delle lingue che la feature dovrà supportare. A differenza di quanto visto fin’ora, questi file dovranno rispettare la sintassi Resources.<cultura>.resx (compreso il file neutro Resources.resx), così facendo questi risulteranno legati unicamente alla singola feature.
In seconda battuta, cambia la sintassi con cui la feature fa riferimento ai singoli file di risorse e con cui vengono recuperati dal motore di provisioning di SharePoint i singoli valori, rispetto alle singole chiavi, in base alla cultura del thread corrente.

$Resources:<chiave>;

Non è più necessario, infatti, definire il nome del file di risorse per prelevare un singolo valore localizzato, ma basta semplicemente la chiave, allo stesso modo in cui non serve più specificarlo all’interno dell’attributo DefaultResourceFile (che in questo caso, deve essere valorizzato con il valore “_Res”).

<?xml version="1.0" encoding="utf-8"?>

<Feature Id="603c8932-7af7-45d0-a8f2-3fe16c5a56b7"

    Title="$Resources:FeatureTitle;"

    Description="$Resources:FeatureDesc;"

    Creator="$Resources:FeatureAuthor;"

    Version="1.0.0.0"

    Scope="Site"

    Hidden="FALSE"

    DefaultResourceFile="_Res"

    xmlns="http://schemas.microsoft.com/sharepoint/">   

</Feature>

Tramite l’utilizzo di uno di questi due metodi, possiamo localizzare tutte le definizioni degli oggetti che desideriamo inserire all’interno delle nostre feature (site column,  content type, list definiton, site definition, ecc…), così facendo questi possono presentarsi nella corretta maniera in quei siti SharePoint creati con lingue differenti gli uni dagli altri.
 
Tags


Destinatari


Prodotti

Microsoft Office SharePoint Server 2007
Windows SharePoint Services 3.0


Bookmark and Share