Di seguito gli interventi pubblicati in questa sezione, in ordine cronologico.
E' da un bel po' che ne ero a conoscenza e così ho deciso di diffondere la cosa anche attraverso il mio blog, ma Skype già dalle versioni non proprio recentissime, presenta una sfilza di emoticon segreti molto simpatici, che funzionano su tanti client.
Se siete utenti Skype provate ad aprire una finestra di Chat e inserite i seguenti codici:
(mooning)
(finger)
(rock)
(smoking)
(toivo)
(headbang)
(drunk)
(bandit)
(~)
(drunk)
(makeup)
(pi)
Ed ecco che avete a disposizione un bel pò di iconcine non listate... Esistono dei testi anche per le bandierine nazionali: provate anche (flag:sigla del paese) ,ad sempio (flag:IT) o (flag:US)
La soluzione è molto semplice per evitare alcune noie tra i browser basati su AppWebKit e il server runtime di ASP.NET.
Basta mettere nel codice di ogni MasterPage queste righe:
if (Request.UserAgent.IndexOf("AppleWebKit") > 0)
{
Request.Browser.Adapters.Clear();
}
In questi giorni sono alle prese con un lavoro di localizzazione di un sito internet in varie lingue, tra le quali molto "estreme" come arabo e cinese e mi sono scontrato con problemi a cui non sono molto abituato, ciononostante in rete ho trovato molto utili alcuni articoli e letture, come quello di Ettore Peyrot postato sul forum di HTML.it, che riporto qui integralmente.
Il problema è che una bandiera, per definizione, individua una nazione e non una lingua. E' quindi sbagliato indicare una lingua con la bandiera di una nazione, per principio. Che molti non lo sappiano (o non ci pensino) e pratichino questo "standard", non cambia nulla sull'errore di principio, e fa sorridere chi di localizzazione e traduzione si occupa per mestiere. L'unica eccezione, volendo essere pignoli, è l'Esperanto, che ha una sua bandiera creata appositamente per identificare la lingua e non una nazione specifica.
Errore quindi, senza dubbio alcuno, ed errore che, oltretutto, comporta conseguenze spesso negative per la "leggibilità" dell'indicazione ed in molti casi anche per la "accettabilità" della stessa da parte di settori più o meno vasti di utenza.
Ovvero, le bandiere UK o US non possono/devono indicare la lingua inglese, che è parlata anche in molti altri Paesi, come la bandiera della Francia non può/deve indicare la lingua francese, quella della Spagna la lingua spagnola, quela del Portogallo la lingua portognese, ecc. La "accettabilità" della indicazione implica che un australiano cliccherà meno volentieri su una bandiera US per leggere una versione in inglese, un brasiliano cliccherà meno volentieri su una bandiera del Portogallo per leggere una versione in portoghese, un messicano/argentino/ecc. cliccherà meno volentieri su una bandiera della Spagna per leggere una versione in spagnolo.
Per non parlare della lingua araba, dove l'utilizzo di una bandiera piuttosto che un'altra può significare il netto rifiuto di visitare una versione linguistica da parte di qualche milione di utenti che vedono tale nazione come fumo negli occhi. Senza dimenticare che la diffusione di Internet in aree geografiche sino a pochi anni fa poco interessanti come bacino di utenza, ma oggigiorno sempre più ricche di possibilità commerciali, rafforza ancor di più situazioni di "inaccettabilità" per un identificativo geografico/nazionale da parte di utenti che parlano determinate lingue, e che possono identificare la bandiera della nazione che "abitualmente" o "istintivamente" (per chi naturalmente ignora tutto o quasi della storia/tradizioni/ecc. locali) viene usata per tale lingua come la "bandiera del nemico/oppressore/traditore".
Molti esperimenti hanno quindi dimostrato come l'utilizzo di bandiere possa ridurre di molto la visibilità di una versione linguistica. Non solo per una questione di "fastidio campanilistico" (es. "sono americano e non clicco su una bandiera UK per leggere una versione in inglese", "sono austriaco e non clicco su una bandiera della Germania per leggere una versione nella MIA lingua madre, il tedesco", ecc...) ma spesso anche per una questione di effettiva "non conoscenza" (quanti brasiliani credete che conoscano e siano in grado di individuare una bandiera del Portogallo come espressione di una versione in portoghese? Quanti argentini credete che conoscano e siano in grado di individuare la bandiera della Spagna come espressione di una versione in lingua spagnola? )
Non è quindi uno sfizio o una inutile ossessione per la precisione dovuta al mestiere nel settore che mi spingono a sconsigliare vivamente l'uso delle bandiere, spiegando l'errore grossolano per l'indicazione di una entità (la lingua) che con una bandiera può avere poco o nulla a che fare.
La soluzione testuale ha dunque il vantaggio di essere quella:
a) corretta,
b) accettabile e perfettamente comprensibile per tutti i potenziali visitatori (anche se di nazionalità diverse) che parlano la lingua così definita,
c) utilizzabile anche come spinta per la keyword della pagina di target.
Ovviamente, in tutti i casi in cui è possibile non parliamo della semplice soluzione testuale indicante il nome della lingua "english - italiano - français - ..." ma di quella indicante l'oggetto/tema/argomento/kwd nella lingua di destinazione "kitchens - cucine - cuisines" (per un sito che tratta, nell'esempio, di cucine appunto).
Questo tra l'altro, comporta anche la codifica della pagina in UTF-8 per consentire l'inserimento di grafie appartenenti a codifiche diverrse (cinese, italiano, russo...) nella stessa pagina mantenendo la leggibilità da parte di utenti e crawler, ma qui andiamo verso l'OT rispetto al tema originario
Nulla da ridire, per concludere, su soluzioni grafiche alternative, se si rieuscisse ad individuarne (usabilità/leggibilità estese sempre considerate nella applicazione grafica, tra l'altro). Ovvero, ad individuare rappresentazioni grafiche che esprimano adeguatamente una lingua e siano allo stesso tempo ben studiate nella localizzazione: attenzione quindi a non esprimere graficamente nulla che non sia comune a tutti coloro che parlano la lingua rappresentata, o ancor peggio che risulti offensivo/sgradito o anche semplicemnente sconosciuto a gruppi di utenti che parlano tale lingua. Nello specifico, l'omino con bombetta è decisamente "British" ed uno statunitense farebbe fatica ad identificarvisi, l'omino con baguette è decisamente orientato alla Francia ed un canadese non lo identificherebbe come proprio.
La localizzazione è una attività complessa, che al di la dei "piaceri" e delle "convinzioni" si deve basare su dati oggettivi ricavati da ricerche, test di utilizzo e di comportamento degli utenti, analisi sulle componenti delle realtà storiche, geo-politiche, economiche, etniche, religiose, culturali, eventualmente coinvolte. In alcuni casi, "bruciare" un 20%, 30 %, 50% o più di utenza potenziale per aver sbagliato una grafica è qualcosa che il cliente finale non è disposto ad accettare (e più spesso di quanto si creda c'è poi qualcuno pronto a farglielo notare se non se ne è accorto subito). Lo dico con conoscenza di causa, dato che l'anno scorso abbiamo quasi raddoppiato gli accessi ad un sito di un nuovo cliente correggendo qua e la alcune inesattezze nelle versioni linguistiche e cambiando le bandiere in link testuali. Errori del Web designer, che aveva affidato la traduzione a personaggi poco competenti, e non sapeva nulla delle necessità di localizzazione.
Qui sotto comunque trovate il thread completo, dove ho scovato il post di Peyrot:
http://forum.html.it/forum/showthread.php?threadid=555590
Spesso non riesco ricordare a memoria la posizione assoluta di dove vengono collocate le pagine del sito su un server, tipo i server virtuali di Aruba, gestito da Virtuozzo e PLesk, ovviamente con sistema operativo Linux. Questa è la posizione assoluta:
/var/www/vhosts/nome_del_dominio_com/
Da lì in poi si possono trovare le effettive pagine e cioè dentro httpdocs/ le pagine standard del sito, mentre nella cartella statistics/ tutte le statistiche del caso.
Oggi non sapevo come fare a fare una valutazione booleana nella generazione del valore di un campo in una SELECT e così ho scoperto che si può fare così:
(CASE WHEN (mytable.myfield = 'VALUE') THEN mytable.anotherfield ELSE 'none' END) AS myEvaluation
Questa sintassi può essere usata sia nel pescare un campo in una SELECT, ma anche nella parte WHERE della medesima SELECT. In sostanza è la stessa cosa che si fa in Visual Basic 6 col costrutto Iif:
myEvaluation = Iif(mytable.myfield = 'VALUE',mytable.anotherfield,'none')
o in linguaggio C col costrutto expr ? positive : negative:
myEvaluation = strcmp(mytable.myfield,'VALUE') == 0 ? mytable.anotherfield : 'none';
Questa sintassi, mi riferisco al SQL, dovrebbe essere valida sia con mySQL che con PostgreSQL.
Una scoperta che ho fatto solo questa sera è che la visibilità di una variabile si limita al contesto in cui essa è definita, cosa non da poco rispetto a quasi tutti gli altri linguaggi.
Ad esempio nel linguaggio C le variabili globali sono automaticamente disponibili in tutte le funzioni, a meno che non siano specificamente sovrascritte da definizioni locali della medesima variabile. Questo può causare alcuni problemi perché può essere che si cambi senza avviso una variabile globale. In PHP pertanto le variabili globali devono essere dichiarate globali all'interno della funzione dove si ha in mente di utilizzarle attraverso la keyword global.
Esiste comunque anche la possibilità di utilizzare l'array associativo $GLOBALS, per il quale si rimanda al manuale del PHP.
Dopo aver contribuito ad aver favorito la diffusione di Libero come provider di servizi di posta elettronica oltreché di connettività al web, mi ritrovo a rimangiarmi tutto da quando Libero ha posto delle limitazioni sullo scaricamento della posta elettronica, via POP3.
Se hai una casella di Libero e non hai una connessione direttamente con Libero o hai pagato loro il servizio aggiuntivo di posta elettronica, non c'è verso di prendersi la posta. Il problema non c'è però solo con Libero, ma sembra che la limitazione sull'accesso POP3 sia un prassi abbastanza comune sulla penisola e non solo: prima di accalappiano promettendo monti e mari gratis, poi sono lì ad elemosinare attraverso fastidiose barriere tecnologiche. E in Italia questa maniera di fare sta prendendo sempre più piede in qualsiasi ambito o settore. Ma "liberi" di cosa?
Ora "mal comune, mezzo gaudio" e qualcuno ha ben pensato di risolvere il problema con un approccio drastico, visto che l'accesso gratuito al servizio di posta elettronica è comunque possibile via web, cioé dal browser. La soluzione è FreePOPs e queste sono le indicazioni precise per configurare il proprio client, come Outlook Express con Libero:
Configurare Outlook Express per funzionare con Libero e FreePOPs
Non posso nascondere che ho sempre tribolato non poco per far comparire il favicon nei vari browser, per i vari siti che ho in gestione.
Il favicon sarebbe quell'iconcina che compare in tutti i browser alla sinistra dell'indirizzo che state visitando. Tale iconcina ha per certi versi un'importanza commerciale a dir poco strategica e non sto qui a illustrarvi tutto, ma si dà il caso che non compare solo a fianco dell'URL, ma anche nella pagina dei bookmark, se memorizzate quell'indirizzo tra i vostri preferiti. In più alcuni browser mostrano tale icona anche nell'eventuale pagina nella loro gestione a pagine.
Ricapitolo pertanto molto brevemente quali sono le cose da sapere per garantire il funzionamento in tutti i browser o quasi, visto che si usa come riferimento Internet Explorer, Mozilla Firefox, Opera e Safari:
Come vedete, il grosso dei problemi li dà Internet Explorer. Tutti gli altri browser sono molto più tolleranti e compatibili.
Da qualche giorno il mio server FTP sul server Tencas - cioè da quando Aruba mi ha reinizializzato il server - succede che parecchi client FTP non riescono più a dialogare col server FTP, perché non sono in grado di supportare una connessione attiva FTP, ma la provano solo in modalità passiva.
Ecco allora come fare per commutare ad esempio il client FTP integrato in Windows Explorer/Internet Explorer di Windows XP per dirgli di andare in modalità attiva:
In alternativa consiglio la lettura di questi articoli:
Dopo aver perso una buona quantità di tempo ieri a causa di svariati malfunzionamenti che si presentavano sul mio server virtuale, ho deciso di reinizializzarlo in modo da guadagnare un sacco di spazio perso per l'effetto perverso del Disk Cleanup sulla partizione virtualizzata da Virtuozzo che riottenere il regolare funzionamento del framework .NET col sistema operativo sottostante opportunamente aggiornato con Windows Update da parte dei gestori di Aruba!
Lunga vita quindi al mio server virtuale e grazie ancora all'eccellente servizio di Aruba!
|