I've started Views translation into German and found some strings that

Isn't it not possible to use plural logic inside views_object_types()?

Sort criteria
Sort criterion

Node revision
Node revisions

Many many other strings are missing periods. It would be *very* helpful if they are there.

The subject of the comment
-> The subject of the comment.

The view has been deleted
-> The view has been deleted.

Strings should not contain HTML code. This is a good example where this could be avoided.

exposed
-> exposed

I'm not a native speaker in English, but shouldn't this be one string? Menu item entry sounds to me like "Menu item item" or "Menu entry entry". Not sure... some seems to be duplicates and could be merged together to get less strings.

Menu item entry
-> "Menu item" or "Menu entry" ?

Normal menu entry = Normal menu item ?
-> merge them into one

This is minor, but for XHTML compliance we should change this to STRONG.

View %name, displaying items of type <b>@base</b>.
-> View %name, displaying items of type <strong>@base</strong>.

Suggestion:

t('Offset')
-> be more specific. This could be so much... time releated, skip items, etc. - It is very difficult and impossible to translate all meanings into one word!

Comments

hass’s picture

Damn HTML filter... :-)

exposed<br />
-> exposed

merlinofchaos’s picture

It would be pretty difficult to switch the logic in views_object_types to format_plural().

I've been trying to add periods to missing strings when I can see them, but they don't exactly jump out at me in the code.

That <br /> probably shouldn't even have been on that exposed strong.

t('Offset') is in a place where brevity is required, as there isn't a lot of space; and I don't have another word for it. That string only appears in that form once, and it is an offset to the number of records.

Menu item entry is the title of the form where you're entering data about a menu item. Nothing else immediately comes to mind as a proper replacement for the title.

BTW, thanks for this work but as we're still in alpha there will probably be significant string changes before we hit beta. (I don't want to discourage you or anything but want to warn you that this translation will probably be bumpy =)

In particular, I went through and added periods to the comment.views.inc strings (which is probably the largest set of offenders) and it's very likely that many of those strings will change. I still haven't made it into that .inc file to clean it up, it needs a fair bit of re-organization.

hass’s picture

Ok, thank you for quick feedback.

t('Offset') could only become an issue if more modules use offset as a word... I could use Offset in German, too - but there are really better words in German that match better and they are longer. But if someone else use Offset it might become the wrong word. Additional French is one of the languages where nearly every string get's longer - keep in mind if this is an issue with space...

I stopped translation after this first commit... it was mainly a try to see what have been changed... and really - there are MANY strings - or better - nearly all changed. Less then ~20% are reusable :-(.

It would took much time to get Views module translated... give us a some time - one or 2 weeks at minimum before a final release, please.

hass’s picture

I reviewed your commit shortly and saw t('exposed>'). Shouldn't this t('exposed')?

merlinofchaos’s picture

Oh absolutely. I will do a string freeze probably around the 3rd or so beta and make an announcement on my blog.

hass’s picture

Found one more string: Unable to find term(s): @terms is a good candidate for plural logic.

drewish’s picture

@hass, Just wanted to comment that in "Menu item entry" entry is used as intransitive form of the verb to enter, rather than a noun.

merlinofchaos’s picture

OH, just to comment:

I stopped translation after this first commit... it was mainly a try to see what have been changed... and really - there are MANY strings - or better - nearly all changed. Less then ~20% are reusable :-(

Views 2 is a ground up rewrite, so this should not be surprising.

moshe weitzman’s picture

Title: A few translatability issues... » Better to describe fields/tables without t() in hook_views_data()
Version: 6.x-2.0-alpha4 » 6.x-2.x-dev

I was a bit surprised to see that field titles and such are wrapped in t(). We moved away from that practice for menus, and just do translation on output. That is much more cache friendly. If we do caching of hook_views_data() info, then the language shown will be that if the person who was active when the cache was last flushed.

Feel free to mark this as won't fix or whatever as needed.

merlinofchaos’s picture

Title: Better to describe fields/tables without t() in hook_views_data() » Translatability issues
Status: Active » Fixed

I have always cached the views data by language. It's pretty hard to do the translation on output since the fields are pretty dynamic and we don't know what/where/when. This is the same method I used in 4.7 and it's worked ok.

Not won't fixing since there's still an issue behind this.

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.