ciao, benvenuto nel forum!
Il routing in questo caso potrebbe non essere un problema. Infatti, quando l'esecuzione arriva alla factory del tuo resource provider, la route è già stata risolta con il percorso virtuale al file aspx.

Mi spiego meglio: avrai sicuramente realizzato una classe che deriva da ResourceProviderFactory. Come parametro del suo metodo CreateLocalResourceProvider gli verrà passato un percorso tipo "/Cartella/Pagina.aspx", indipendentemente dalla route usata per arrivarci.

Quindi non devi ricavarti alcun percorso, ti viene già fornito come serve a te.

Lo user control che hai in amministrazione dovrà usare anch'esso un percorso come quello lì. A questo punto dovreti aver risolto perché si tratta del percorso di una pagina.aspx fisicamente esistente su disco.

Può funzionare?

ciao SlowFox,
ok, ora penso di aver capito.
Comprendo che tu voglia "unificare" la gestione dei testi tradotti ma probabilmente dovresti tenere separate le risorse locali, cioè quei testi come "Aggiungi al carrello" propri della pagina aspx, dalle descrizioni prodotti.

Può capitare infatti di dover presentare un prodotto anche in altri punti dell'applicazione, come in una pagina di ricerca oppure nella vetrina in homepage. In questo caso legheresti le descrizioni anche a quelle altre pagine?

No, è preferibile che i contenuti restino agnostici sul come poi verranno presentati nel sito.
Per i prodotti, potresti predisporre nel database una tabella secondaria che conterrà i testi tradotti ed avrà una chiave primaria composta da due campi: l'id del prodotto e l'id della lingua. Qui trovi una possibile implementazione, vedi il paragrafo "The good design".
http://www.codeproject.com/Articles/8084/Creating-multilingual-websites-Part-2#databasedesign

Il tuo strato di accesso ai dati dovrà dunque mettere in JOIN la tabella principale dei Prodotti e quella secondaria che contiene le traduzioni. Nella clausola ON della join, andrà indicato anche il criterio della lingua, in modo che tra le tante traduzioni sia scelto solo il record relativo alla lingua dell'utente.
Trovi l'esatta query SQL nello stesso articolo che ho linkato qui sopra.

SlowFox ha scritto:

dovrei passare i parametri idProdotto e idCategoria per avere qualcosa di univoco

Da questo punto di vista, conoscere l'idProdotto e l'idCategoria non ti serve più perché l'inserimento delle traduzioni avverrebbe dalle pagine di amministrazione dello specifico prodotto o categoria.

Nella pagina di modifica prodotto potresti predisporre un editor del genere, avente tante tabs quante sono le lingue disponibili nel sito.
http://help.convio.net/images/content/pagebuilder/TabsEditorEnglish.png
Al salvataggio, ogni contenuto tradotto verrebbe poi inserito nella tabella secondaria di cui parlavo.

ciao

---

Modificato da BrightSoul il 09 maggio 2013 23.26 -

ciao, prego :)

SlowFox ha scritto:

richiederebbe troppe risorse lato server localizzare gli oggetti prodotto e categoria con risorse globali?

Immagino che tu possa farlo, e con pochi utenti contemporanei potrebbe funzionare egregiamente. Tuttavia, non è una soluzione che mi sento di consigliarti, in primo luogo perché penso che snaturi lo scopo delle risorse globali che è quello di contenere piccole porzioni di dati da condividere attaverso molteplici pagine.
L'altro motivo è che, se in una scheda prodotto impieghi 4 o 5 risorse globali (es. titolo, sottotitolo, descrizione e scheda tecnica), il tuo provider custom dovrà effettuare altrettante query SELECT al database. Invece, potresti ridurre il numero ad 1 se con una sola query recuperassi contemporaneamente tutti i campi da mostrare nella pagina.

Certo, nel provider custom potresti impiegare un meccanismo di caching per mitigare il problema di accesso al database, ma a quel punto dovrai fare attenzione alla RAM occupata dalle risorse. Con migliaia di prodotti e descrizioni abbastanza corpose, questo potrebbe diventare un problema.

Nel dubbio, personalmente cercherei di seguire la soluzione che riesce a darmi il miglior risultato con il minor dispendio di risorse. In questo caso si tratterebbe di recuperare i dati di un prodotto con un'unica SELECT ... JOIN tra la tabella principale e quella correlata che contiene i testi tradotti.
Se ci pensi, il lavoro di progettazione da fare a livello di database è lo stesso sia che usi l'uno o l'altro sistema. Si tratta comunque di creare una tabella con una chiave primaria composta da lingua e identificativo del prodotto.

ciao