search

ryancramerdesign / ProcessWire

Our repository has moved to https://github.com/processwire – please head there for the latest version.
https://processwire.com
Other
727 stars 198 forks source link

multilanguage URL fieldtype #1059

Open er314 opened 9 years ago

er314 commented 9 years ago

In addition to TextLanguage and TextareaLanguage fieldtypes, I would see a use for also having URLLanguage fieldtype.

For example, let's imagine that I'm publisher of a blog-like website which talks about bicycling, and this website is in English + German. Today, I write an article about a very nice website which I like : www.tripsite.com So in my TextAreaLanguage field, I explain both in English and in German how much I like and recommend this website. Then in my URLLanguage field, in the very same manner, I set the following 2 links, for each language respectively : http://www.tripsite.com/ , http://www.tripsite.com/de/

From the developper/API point of view, this also seems consistent (instead of having to fallback on using a TexLanguage field for handling a "multilanguage URL")

jacmaes commented 9 years ago

+1

er314 commented 9 years ago

Just to further give my broader view on this multilanguage subject : Actually, not only URL fieldtype could benefit from supporting URLLanguage variant, but, more generally, I think that almost every fieldtypes could benefit from having a multilanguage variant : IntegerLanguage, even CheckboxLanguage, ...

For instance, let's say that I have a multilanguage site, with a template for describing music albums. I will of course have a TextAreaLanguage field, for the textual description of the album. l will also have an Integer field, used for the top billboard ranking of the album. And, as my site is multilanguage, I want the ability to populate this field with the album's top billboard ranking relevant to each country ; or API to fallback using the default language's value, if some languages are not populated. -> hence, the need for IntegerLanguage fieldtype.

I hope it makes sense.

somatonic commented 9 years ago

That's what alternative language fields are made for. They behave like language fields and can be used for any field. You name them: checkbox, checkbox_de, checkbox_fr ...

er314 commented 9 years ago

Thanks for the heads up Soma. After reading the documentation, I agree that, as long as the need is sparse (not too many different languages, and not too many fields involved), then it's realistic to do the necessary fields duplications, and this "alternate language fields" does fit the bill

teppokoivula commented 9 years ago

Language alternate fields are a valid solution, but in the long run it would be nice to see a wider range of multi-language fields, even if for the sake of consistency. Working with multi-language fields is nice and consistent using the setLanguageValue() and getLanguageValue() methods; they take all the guesswork away and simplify things.

Perhaps a bit off-topic, but I don't particularly like that we have two methods of getting (almost) exactly the same result in relation to multi-language fields: actual multi-language fields, and language alternate fields. I've been wondering if we could drop the latter at some point, simply making it so that all fields would be "multi-language aware".

Anyway, that's probably way more complicated from technical point of view than I can think of right now. I just happen to enjoy simplicity very much, and having multiple, competing, built-in methods of doing the same thing (such as handling language values) is a complication I'd like to get rid of :)

ryancramerdesign commented 9 years ago

I agree that it would be worthwhile to add more multi-language Fieldtypes. Though there haven't been many asking for it yet, but I would really like to have them too. It would also be relatively easy to implement for many of the basic core types (numbers, dates, checkbox, etc.), as the interface is already established and working well (LanguagesPageFieldValue interface). If you look at the existing multi-language Fieldtypes (FieldtypeTextLanguage, FieldtypeTextareaLanguage, FieldtypePageTitleLanguage) they are among the simplest Fieldtypes there are, needing only a few lines of code that extends their base type.

Most Inputfields don't even need to be aware of multi-language, since the LanguageSupport module takes care of making them multi-language via hooks to render() and processInput(). Though I think Language Alternate fields will always fill an important role either way because they can literally take any field and make it multi-language, no matter how complex. For instance, take the need of having a separate repeater or PageTable for each language (rather than a repeater or PageTable with multi-language fields). Or take the need of a 3rd party Fieldtype where the author has no plans to support multi-language natively... Language Alternate fields make it possible to support it without the original author intending to.

On Sun, Jul 12, 2015 at 2:19 PM, Teppo Koivula notifications@github.com wrote:

Language alternate fields are a valid solution, but in the long run it would be nice to see a wider range of multi-language fields, even if for the sake of consistency. Working with multi-language fields is nice and consistent using the setLanguageValue() and getLanguageValue() methods; they take all the guesswork away and simplify things.

Perhaps a bit off-topic, but I don't particularly like that we have two methods of getting (almost) exactly the same result in relation to multi-language fields: actual multi-language fields, and language alternate fields. I've been wondering if we could simply drop the latter at some point, simply making it so that all fields would be "multi-language aware".

Anyway, that's probably way more complicated from technical point of view than I can think of right now. I just happen to enjoy simplicity very much, and having multiple, competing, built-in methods of doing the same thing (such as handling language values) is a complication I'd like to get rid of :)

— Reply to this email directly or view it on GitHub https://github.com/ryancramerdesign/ProcessWire/issues/1059#issuecomment-120752250 .