To add Translate token to TextTokens

[jersiovic]

It is useful to have the possibility of getting the value returned by a token translated to the current culture.

I would like to add Translate token to TextTokens. It is a very easy feature to add, What do you think of adding it to the core? If you accept it can you assign me the issue in order to submit a pull request?

[Piedone]

You mean like having a token that takes the output of the previous token and wraps it into a T()? Or what do you have in mind?

[Skrypt]

I'm not sure either on this. You should translate your entities ... not the tokens. I would say, like @Piedone, do you have an example of what you want to achieve ?

[jersiovic]

Yes @Piedone it is just that. But only for text not for content. This answer also your question @Skrypt ? It will translate text not complete entities.

Here is an example of my definition of the token http://orchard.codeplex.com/discussions/641309

[jersiovic]

A case of use. I have an html widget where I use tokens to render another time the title of a page (it was not enough with the one of the titlePart shape). This is the token

{Content.Current.DisplayText}

What if the page needs to support more than one culture? I would like to have the Translate token for chaining it to text outputs like the one returned by DisplayText.

{Content.Current.DisplayText.Translate}

[Piedone]

I see the issue and how this would be useful. Though unfortunately it would be hard to actually utilize this, as you'd need to write localized strings for each of the possible inputs but targeted at the token provider.

[Skrypt]

You should also be able to create a widget for each culture by adding Localication to the HTML Widget content type. Then your title would already be translated in each of those widgets.

[jersiovic]

Yes, you are right, I use this solution on this customer cause for some reasons we don't want to use the duplication of content items per language for certain content types. So, it is only useful for me in this specific circumstances.

[jersiovic]

@skrypt I don't see how localization on html widget can help here. If what I want is to translate current Content Item title the localization part should be at that content item.

I closed the issue because what pointed @Piedone sounds sensible. I'm forced to have translations for my Content titles in .po files and this initially is not a good idea.

So what I have to do is to use localization part for those content types for which I want to another language version. So Translate() token is don't needed because the content item that will be rendered will be just the one with the current language.

The reason why I have reopened the issue is what if I want to translate a projection? No problem, I use a culture filter to force only current culture items are shown by the related query. But how do I translate the title of the projection? To add the localization part to ProjectionPage type is something I don't like. Cause it forces the user to maintain duplicated projections only by the title. Forcing it to remember repeat changes in other properties different from title (the query, the number of items to show, ...) per each culture is adding too much complexity just because you want a translated title.

So, for the sake of simplicity for the user I prefer to add T() to title projections template and avoid use localization part on Projections. So, at this point Translate token is useful. Don't you think duplication of content item in a projection is a bit too much?

Yes I need to add manually to .po file the translation of new projections but new projections added by a user are something doesn't happen frequently. It usually is done by me in migrations.

Related to make available the translations of .po files to user, through UI maybe this could be the solution http://orchard.codeplex.com/discussions/641356 . I will give it a try to make it work on an Orchard upper version.

At the end of the day I think duplication of content and .po files are valid solutions with their pros and cons. So is good to make it easy to the user combine both to help him make the experience easy.

[Skrypt]

Normally the Query that I create have english titles because it is something that most users won't have access to modify. Then I will create a projection for each culture installed in Orchard. I do this because I need to have a different URL for each of those projection pages. So, the title of those projections will be translated. I don't let any editor to be able to change the queries because they could break them.

I understand though that at some point you can't translate every content items to makes this easier for your website editors. I use .po for instance to translate content type names and admin menu names. Though having a way to make this easier would be to have a .po editor inside Orchard that could tell us wich translated string is missing a translation. Then being able to edit those in place. This is a topic that would need to be discussed to find wich way is the best to go.

Keep this issue opened ;)

[sebastienros]

This is not the first time someone raises the concern. It applies to anything that is in the db and is not a content item data, like field names, content type names, messages in workflows, ... In the end the localization has to be in a po file and this is not manageable.

I think we could have an ad hoc localization strings page that would also taken into account during translation. This way whenever a dev would create a fiel name or workflow string he could add an entry in this page. A specific permission would allow other contributors to edit the translations. This module could even show the technical elements we know are displayed in the ui (like field names).

Another enhancement could be to display the strings which translations haven't been found at some point in time(as an optional feature).

[jersiovic]

+1 It sounds very convenient.

Related with the multilanguage topic. Many times I have the sensation that should exist another approach for localizing contents different from .po files and localization part in order to avoid not necessary data duplication

What if parts or fields could be configured as localizable at type level?

For example think you can configure Title part within the ProjectionPage type as localizable. Then when you edit a ProjectionPage content item the UI will offer you a way to complete title for each one of the languages supported by the site. In that way you don't need to duplicate all the content item just because you want to localize only one part. The same approach could by used for fields.

Maybe this is a solution that you have discarded in the past because it has problems I'm not able to see now or because it is complex of develop.

[sfmskywalker]

@sebastienros +1 I had the same idea of havng an ad hoc localization strings page.

[sfmskywalker]

@jersiovic I had that thought as well initially, but then realized there are many more places that we may need to localize, then concluded a central localization page would make sense (maybe categorized so we have a group of content type translations grouped together).

[jersiovic]

@sfmskywalker I see the central localization page is something we need. The localization per part/field in a content item I think is complementary

[sfmskywalker]

Yeah I agree it would be nice to have it there as well actually. Maybe like it's done with the AutoroutePart settings using a tabbed UI.

[jersiovic]

Yeah just that :)