On 5/3/01 5:45 AM, "Jean-S�bastien Lebacq" <[EMAIL PROTECTED]> wrote:
>> perhaps we can think of a more generic structure so that we can both
>> isolate the code as needed as well as provide meaning full reports to user.
>> Any thoughts would be appreciated.
>
> If I have perfectly understand, we have a problem when we want to show words
> which are function of one variable or more. So, I think a solution is create
> a function the result of which is a string. And that function is adapted for
> each language.
> So, in function.php, the function and procedure aren't function of the
> language, they just call the �nationalized� functions which are in a
> different file.
> I know that solution implies you leave php code in the lang/ directory, but,
> for the moment, I don't see another solution which can adjust to every
> language.
How about this...
in the case of language-provision-report we are trying to communicate 3
things. the languages we tried to provide but could not, the language we
eventually did provide, and a link to more information about translations on
the site.
in the case of translation-lag-report we are trying to indicate one thing,
that the current page viewed is less recent than that of the same page in
BASE_LANG (in freenet's case, english. i don't want the system to be
arbitrarily based on english being the assumed to be the fallback language,
hence the shift to BASE_LANG.)
we could perhaps compromise between where things were, where they are and
what you have suggested by providing arrays with the languages. The
formatting of the notification <table> could remain in functions.php for
uniformity across languages. The translation contributors would be
responsible for presenting that information as best they can without being
forced to work around English syntax or any other syntax not their own. I
don't know if we can assume translators to program in PHP, but there is lots
of help available.
Thoughts?
Rick
p.s. Another thing on my list is to intelligently deal with the relative
equivalence of [en] and [en-gb] and the distinctiveness of [zh] and [zh-tw].
in the former case transparently displaying [en] content when [en-gb] is
requested is fine, in the case of the chinese dialects, it is not. lots of
special cases to deal with.
> If we use that system, we must answer to an another question : how can we
> combine two �nationalized� functions ? I think it's only possible if the two
> strings are sentences. So, all the result of �nationalized� functions must be
> a sentence or several sentences. Even the period is included in the string,
> because :
> - in english : enjoy Freenet!
> - in french : amusez-vous avec Freenet !
> But :
> - in english : enjoy Freenet.
> - in french : amusez-vous avec Freenet.
>
> Moreover, if a new �nationalized� function is created, as long as that
> function has not his french or deutch version, we simply use the english
> version : one english sentence in a page is not a catastrophe, and is better
> than no sentence at all.
> And, for sentences like "There is a more recent version of this document
> available here", why not give the priority to the more recent english version
> instead of the old french version, if you modify that �nationalized� function?
>
> That's the only solution I see.
>
> Regards, JSL.
>
>
> _______________________________________________
> Web mailing list
> [EMAIL PROTECTED]
> http://www.uprizer.com/mailman/listinfo/web
_______________________________________________
Web mailing list
[EMAIL PROTECTED]
http://www.uprizer.com/mailman/listinfo/web
