You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@httpd.apache.org by Nilgün Belma Bugüner <ni...@belgeler.gen.tr> on 2008/07/02 10:52:49 UTC
Image file translations
Hi,
I have translated the image files in filter.xml into Turkish. But I
guess you do not have a solution yet for image file translations. (The
package I sent to the list earlier did not any attention).
I think it will be a good start if I stress the need to do the following
changes in "httpd-manual.conf.in" file:
Index: conf/extra/httpd-manual.conf.in
===================================================================
--- conf/extra/httpd-manual.conf.in (revision 672463)
+++ conf/extra/httpd-manual.conf.in (working copy)
@@ -14,13 +14,16 @@
AllowOverride None
Require all granted
- <Files *.html>
+ <Files ~ "\.(html|png)$">
SetHandler type-map
</Files>
# .tr is text/troff in mime.types!
<Files *.html.tr.utf8>
ForceType text/html
</Files>
+ <Files *.png.tr.utf8>
+ ForceType image/png
+ </Files>
SetEnvIf Request_URI ^/manual/(de|en|es|fr|ja|ko|pt-br|ru|tr)/ prefer-language=$1
RedirectMatch 301 ^/manual(?:/(de|en|es|fr|ja|ko|pt-br|ru|tr)){2,}(/.*)?$ /manual/$1$2
The reason I only cover PNG files is that I want to find a solution to
exclude the files that require no translation. I suggest the following
rule to be observed from now on: "The image files that require no
translation should not be of PNG type."
Therefore after doing
$ rename 's/\.png$/.png.en/' *.png
on PNG files under "images/", the same files will be replaced by the
a type-map file:
$ cat filter_arch.png
URI: filter_arch.png
URI: filter_arch.png.en
Content-type: image/png
Content-language: en
URI: filter_arch.png.tr.utf8
Content-type: image/png
Content-language: tr
That is all. I do not cover the further task of copying the translated
image files into offline document folders with bare .png extension.
This is beyond my reach.
Best regards,
Nilgün
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Image file translations
Posted by André Malo <nd...@perlig.de>.
* William A. Rowe, Jr. wrote:
> Tony Stevenson wrote:
> > Agreed, this would seem to be the simplest and cleanest solution.
> > I'm not sure mucking about with language negotiation will offer us
> > other than additional headaches.
> >
> > Then using ForceType will likely cause some browsers to make a right
> > royal hash of it all. IE8 for example, refuses to display
> > foo.png.tr(.utf8) instead offering to give me it's traditional red x.
>
> Keep in mind, too, that rendering these from the file system, our
> inverted file types are a real headache. Ending in .png as suggested,
> or .html or whatnot is far more rational, and the original convention was
> certainly a flaw from the point of view of a browser reading our content
> locally.
For local viewing we've got the localized archives anyway. I think, that
should be fine.
nd
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Image file translations
Posted by Tony Stevenson <to...@pc-tony.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
William A. Rowe, Jr. wrote:
| Tony Stevenson wrote:
|>
|> Agreed, this would seem to be the simplest and cleanest solution.
|> I'm not sure mucking about with language negotiation will offer us other
|> than additional headaches.
|>
|> Then using ForceType will likely cause some browsers to make a right
|> royal hash of it all. IE8 for example, refuses to display
|> foo.png.tr(.utf8) instead offering to give me it's traditional red x.
|
| Keep in mind, too, that rendering these from the file system, our inverted
| file types are a real headache. Ending in .png as suggested, or .html
| or whatnot is far more rational, and the original convention was certainly
| a flaw from the point of view of a browser reading our content locally.
|
Good point Bill, yes we do also need to make sure that the docs pages
can be viewed locally from the local FS.
To that point, I suggest that we use the following naming convention for
all non-English images:
foo.locale.extentsion --> rewritemap.fr.png
Thus incorporating locale, but still retaining the proper file extension
for local FS viewing.
- --Tony
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhr/NQACgkQyceSTlEEfWYQMQCfR+Xx1XH3MA1VmO6F+J5qN/cA
uKgAn3qNHWJybm8xezRxiwrLduwsXs7I
=n3et
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Image file translations
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Tony Stevenson wrote:
>
> Agreed, this would seem to be the simplest and cleanest solution.
> I'm not sure mucking about with language negotiation will offer us other
> than additional headaches.
>
> Then using ForceType will likely cause some browsers to make a right
> royal hash of it all. IE8 for example, refuses to display
> foo.png.tr(.utf8) instead offering to give me it's traditional red x.
Keep in mind, too, that rendering these from the file system, our inverted
file types are a real headache. Ending in .png as suggested, or .html
or whatnot is far more rational, and the original convention was certainly
a flaw from the point of view of a browser reading our content locally.
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Image file translations
Posted by Tony Stevenson <to...@pc-tony.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
André Malo wrote:
| * Nilgün Belma Bugüner wrote:
|
|
|> Hi,
|>
|> I have translated the image files in filter.xml into Turkish. But I
|> guess you do not have a solution yet for image file translations. (The
|> package I sent to the list earlier did not any attention).
|
| You're expecting too much ;-). People are not instantly following
every post
| here.
|
| Anyway, regarding images I'd suggest a more simple approach:
|
| Name the translated images e.g. foo.tr.png and link them directly from
the
| translations. I don't see much sense in negotiating the image
languages, as
| they are only useful in the context of the translations themselves.
|
Agreed, this would seem to be the simplest and cleanest solution.
I'm not sure mucking about with language negotiation will offer us other
than additional headaches.
Then using ForceType will likely cause some browsers to make a right
royal hash of it all. IE8 for example, refuses to display
foo.png.tr(.utf8) instead offering to give me it's traditional red x.
André's idea of linking directly would seem to be the better of the two.
- --Tony
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhr+TwACgkQyceSTlEEfWafaACfQupayDw56pXDLqn//ayvVIOc
g5MAn1iK/pPnwkW+UXjSWDrA+ksfeedt
=Kc1Y
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Image file translations
Posted by André Malo <nd...@perlig.de>.
* Nilgün Belma Bugüner wrote:
> Hi,
>
> I have translated the image files in filter.xml into Turkish. But I
> guess you do not have a solution yet for image file translations. (The
> package I sent to the list earlier did not any attention).
You're expecting too much ;-). People are not instantly following every post
here.
Anyway, regarding images I'd suggest a more simple approach:
Name the translated images e.g. foo.tr.png and link them directly from the
translations. I don't see much sense in negotiating the image languages, as
they are only useful in the context of the translations themselves.
Opinions?
nd
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org