Hi,
sorry for my late reply, i was notified in a mailthread this question
caused and did not look close enough where it was originated.
so here is my comment:
if there is any way to tell which links are localized and which are not
I can add it to gsicheck.
could I assume e.g. that all localiteable links start with http:
or all not localizeable links refer to xhp fules (end with .xhp)?
please let me know. But be aware that this rule must be correct for ALL
links, no exception allowed.
Best write an issue to me so I will get to it for sure.
Gregor
Clytie Siddall schrieb:
Hi everyone :)
When we translate the Help, there are quite a few strings where the user
needing help is referred to mailing lists, webpages or other support
resources.
The original string contains the English resource, which is not useful
to users of other languages.
Even if it were possible for all of these resources, they do not have
language-bars, or content-negotiation which automatically provides a
page in the correct language for that user.
I have found that if I replace the English resource with the one that is
useful for my language, e.g. replace <[EMAIL PROTECTED]> with
<[EMAIL PROTECTED]>, gscheck reports that as an error.
If I add a separate link for the localized resources, gsicheck also
reports that as an error.
How can we deal with this problem? Our users need the localized Help to
direct them to localized support resources, not English resources they
can't read.
Thankyou for any help you can offer with this. :)
from Clytie
Vietnamese Free Software Translation Team
http://vnoss.net/dokuwiki/doku.php?id=projects:l10n
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
