forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira ...@upaya.co.uk>
Subject Re: i18n suggestion
Date Wed, 17 Mar 2004 15:02:44 GMT
Sjur Nørstebø Moshagen wrote:

> På 17. mar. 2004 kl. 15.55 skrev Upayavira:
>
>> Sjur Nørstebø Moshagen wrote:
>>
>>> På 17. mar. 2004 kl. 15.20 skrev Juan Jose Pablos:
>>>
>>>> I do not know how the CLI follow the links, but maybe we can create 
>>>> a <DIV> element with all the languages available for that file. 
>>>> Then ask CLI to use the @hreflang to determine if needs to follow 
>>>> or not.
>>>
>>>
>>>
>>> Great! That would as well be a perfect starting point for creating a 
>>> language menu for users that need to override content negotiation - 
>>> the menu would reflect the available languages for the page, which 
>>> is what you normally want.
>>
>>
>>
>> And how do you maintain that? Now, instead of just dropping a source 
>> xml file into the relevant folder, you've got to add a reference to 
>> it to some other source file. Isn't that just another thing to maintain?
>
>
>
> Sorry, should have been more clear:
>
> No, on the contrary. The idea is to create the menu automatically, 
> based on the suggestion from Cheche (if it is feasible). The whole 
> process would go something like this:
>
> - create a <div> with all available locales for the source file
> - use it for what Cheche had in mind
> - reuse and remold it as a language override menu: this step has to be 
> different for the servlet and the static versions, as they have 
> different capabilities regarding content negotiation and overriding 
> possibilities; this also includes replacing locale codes with human 
> readable language/locale names
> - place the final div somewhere adequate on the output html page
>
> If you drop a file in an appropriate directory, the first step above 
> would pick it up the next time you run forrest, and a new language 
> would appear on the final page. I see no need to maintain anything, 
> except somewhere a catalog of locales and their corresponding natural 
> language names (but locale codes would be ok as well, if you know your 
> audience).


But to do that, you've got to do all sort of directoryGenerator 
handling, to look into the source folder, and find all of the files that 
are translations of this particular page and then convert that into the 
<div> that Cheche mentioned. That is quite a bit of processing to add to 
every page.

Also, I don't like the idea of the CLI having to rely upon some content 
of the page (other than links), especially something we arbitrarily add. 
It means that the CLI will no longer work on ordinary sites, unless 
someone codes them specifically for use with the CLI.

So I'm not really happy with this approach. For now, though, I've not 
got a better suggestion

Upayavira



Mime
View raw message