netcore net configuracion asp asp.net image localization globalization

asp.net - configuracion - set default culture asp net core



Localiza imágenes en ASP.NET (5)

Hace un par de años, tuvimos un diseñador gráfico para renovar nuestro sitio web. Sus resultados se veían geniales, pero desafortunadamente introdujo una nueva fuente no soportada por el navegador web.

Al principio, yo estaba como, "¿Qué!?!" ... ya que la mayoría de nuestro contenido es dinámico y no había una manera real de predefinir todas las imágenes. También estaba la cuestión de los idiomas múltiples (ya que sabíamos que el español estaba en el horizonte).

De todos modos, decidí crear algunas clases para autogenerar imágenes a través de GDI + y programarlas en memoria caché según sea necesario. Esto resolvió la mayoría de nuestros problemas iniciales. Sin embargo, ahora que nuestra carga se ha incrementado dramáticamente, ha habido una fuga en nuestro servidor de interfaz de usuario.

Ahora a la pregunta ... Estoy buscando reemplazar la mayoría de las imágenes dinámicas GDI + con una fuente de navegador web estándar. Estoy pensando en conservar algunas de las imágenes GDI + renderizadas y ponerlas en un archivo resx, pero tengo previsto reemplazar la mayoría de ellas con fuentes Tahoma o Arial mediante asp: Labels.

¿Cuál crees que es una mejor solución de imagen localizada?

  • Incrustar imágenes en el resx
  • Solo agregando la url de la imagen en el resx
  • Alguna otra solución

Mi principal preocupación es limitar el procesamiento en el servidor de la interfaz de usuario. Si ese es el caso, ¿sería mejor agregar la URL de la imagen al resx en comparación con la incrustación de la imagen en el archivo resx?


Debido al almacenamiento en caché, prefiero agregar solo la URL de la imagen al resx. El almacenamiento en caché es mucho mejor para el contenido estático (es decir, archivos sin formato) que para el contenido generado.


Sería muy cauteloso acerca de poner texto en las imágenes en absoluto, CSS con la fuente apropiada de la familia de la fuente es probablemente la respuesta correcta sobre la accesibilidad y buenos motivos de MVC.

Donde realmente se requiere generación, creo que Kiblee y JayArr esbozan buenas soluciones


Solo debe generar cada imagen una vez y luego guardarla en el disco duro. La carga en su sitio no debe aumentar la cantidad de procesamiento que tiene que hacer. Habiendo dicho eso, casi parece que estás usando imágenes para cosas que no deberías ser. Si hay tantas imágenes diferentes que no puede mantenerse al tanto de generarlas, es hora de abandonar sus imágenes de lujo por cosas que no deberían ser imágenes y volver al texto directo. Si el usuario no tiene instalada la fuente especificada, debería recurrir a una fuente similar. CSS tiene un buen soporte para esto.


Tuve el mismo problema hace unos años y nuestro equipo de interfaz nos señaló SIFr. http://wiki.novemberborn.net/sifr/

Incrustas tu fuente en una película Flash y luego utilizas SIFr JavaScript para convertir dinámicamente tu texto en tu fuente. Debido a que es del lado del cliente, no hay impacto en el lado del servidor.

Si el usuario no tiene instalados Flash o JavaScript, obtiene la fuente más amigable para la web.

Como una ventaja adicional: debido a que su contenido sigue siendo de texto, Google puede buscar e indexar el contenido, una gran optimización de SEO.


ver mi respuesta aquí

Esto puede hacerse manualmente o utilizando algún tipo de sistema automatizado (CMS).

El método básico es almacenar en caché sus imágenes en una estructura de directorio específica del idioma y luego escribir un controlador HTTP que elimine efectivamente la capa de directorio adicional. p.ej:

/images/ /en/ header1.gif /es/ header1.gif

En su marcado o CSS simplemente haría referencia a /images/header1.gif. El http hander usa la sesión (si el idioma es específico del usuario) o la configuración (si es específica del sitio) para elegir desde qué directorio servir la imagen.

Esto proporciona una línea limpia entre código y contenido, y permite el almacenamiento en memoria caché del lado del cliente. Resx es ideal para cadenas pequeñas, pero prefiero un sistema como este para imágenes y contenido más grande. especialmente en la web, donde normalmente es fácil cambiar las imágenes.