New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ftintitle: Add support for other languages #1060

Closed
elfez opened this Issue Nov 4, 2014 · 5 comments

Comments

Projects
None yet
3 participants
@elfez

elfez commented Nov 4, 2014

I have a few Spanish language tracks which use "con" instead "feat". It would be nice if it could detect these and handle them appropritately. Presumbly this is going to hold true for other languages as well, so perhaps having some way of providing alternatives on the command line might be more flexible than hardcoding it in?

Really useful plugin btw, so thanks :)

@Kraymer

This comment has been minimized.

Show comment
Hide comment
@Kraymer

Kraymer Nov 4, 2014

Collaborator

This problematic arises in lyrics plugin too.
Maybe a global lang config setting, based on what whe could adapt the behaviour of relevant plugins?

Collaborator

Kraymer commented Nov 4, 2014

This problematic arises in lyrics plugin too.
Maybe a global lang config setting, based on what whe could adapt the behaviour of relevant plugins?

@sampsyo

This comment has been minimized.

Show comment
Hide comment
@sampsyo

sampsyo Nov 5, 2014

Member

¡Bueno! Should be an easy change if you're interested in contributing.

Member

sampsyo commented Nov 5, 2014

¡Bueno! Should be an easy change if you're interested in contributing.

@Kraymer

This comment has been minimized.

Show comment
Hide comment
@Kraymer

Kraymer Nov 5, 2014

Collaborator

@sampsyo don't you think it would be the occasion to tackle i18n issue in a less bitesized way ?

I'm thinking having a global setting option to specify additional languages and tracking the translations in a resource file (gettext module?). So we could write code like :

   keywords = ['cover', 'lyrics']
   keywords += i18n_whatever(keywords, config['lang'])

We don't have much translations to do yet, but with this in place we could eventually translate the whole beets interface in other langages?

Collaborator

Kraymer commented Nov 5, 2014

@sampsyo don't you think it would be the occasion to tackle i18n issue in a less bitesized way ?

I'm thinking having a global setting option to specify additional languages and tracking the translations in a resource file (gettext module?). So we could write code like :

   keywords = ['cover', 'lyrics']
   keywords += i18n_whatever(keywords, config['lang'])

We don't have much translations to do yet, but with this in place we could eventually translate the whole beets interface in other langages?

@sampsyo

This comment has been minimized.

Show comment
Hide comment
@sampsyo

sampsyo Nov 5, 2014

Member

Indeed, internationalizing the whole interface would not be bite-sized. 😃 For this particular ticket, though, it might be nice for the marker set (feat., featuring, etc.) to be extended even when you only have a few tracks from a different language (as @elfez seems to have). So it might be nice to add con independent of a global language setting.

Member

sampsyo commented Nov 5, 2014

Indeed, internationalizing the whole interface would not be bite-sized. 😃 For this particular ticket, though, it might be nice for the marker set (feat., featuring, etc.) to be extended even when you only have a few tracks from a different language (as @elfez seems to have). So it might be nice to add con independent of a global language setting.

@Kraymer Kraymer self-assigned this Dec 13, 2014

@Kraymer

This comment has been minimized.

Show comment
Hide comment
@Kraymer

Kraymer Dec 13, 2014

Collaborator

ok I've done it, writing unit tests for ftInTitle plugin now

Collaborator

Kraymer commented Dec 13, 2014

ok I've done it, writing unit tests for ftInTitle plugin now

sampsyo added a commit that referenced this issue Dec 16, 2014

Use a non-capturing group by default (#1060)
Now clients don't have to decide whether they need parentheses or not.

sampsyo added a commit that referenced this issue Dec 16, 2014

Simplify word boundaries (#1060)
Use lookahead/lookbehind matching to ensure there is whitespace around the
token. Replaces the use of \b, which doesn't work for "ft.", etc.

@Kraymer Kraymer closed this in 91a998d Dec 16, 2014

sampsyo added a commit that referenced this issue Dec 16, 2014

More flexible title splitting (#1060)
These tokens should not be artist-exclusive.

sampsyo added a commit that referenced this issue Dec 16, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment