English > Feature Suggestions

Vote: Features for 0.9.9

<< < (23/39) > >>

nostra:

--- Quote ---to have custom fields for persons
like they are existing for movies already
and
--- End quote ---

This does not fit into 0.9.9 any more, but for 1.0 maybe...


--- Quote ---(this might be more difficulty)
an integreation of custom fields into advanced search
--- End quote ---

100% will be available in 0.9.9


--- Quote ---to solve language related problems
in a proper way it might be usefull to have
a language specific replace-list
--- End quote ---

I think we have discussed this topic already and I find the suggestion good, but there some problems with it:
1. Pretty much work for me
2. Too many values have to be translated in too many languages
3. Setting up these replacements will be time consuming

meriator:

--- Quote ---I think we have discussed this topic already and I find the suggestion good, but there some problems with it:
1. Pretty much work for me
2. Too many values have to be translated in too many languages
3. Setting up these replacements will be time consuming
--- End quote ---

You have to translate not even a single word
May be the way I tried to explain my idea has been not clear enough?

lets take an example
1. way

--- Quote ---at view-time (db-data is keeped in orginaly language and will be only processed for viewing)
--- End quote ---
When the program is going to display an genre-term
and the user-preferences is setup to use replacements
only the SQL-Statment has to be changed, joining the replacment-table, to lookup a replace-term
if there is found one the program will take this term otherwise it will take the original term
so there should be a function at the right place to do it
if user-preferences is set up not to do so, this part will be skiped at all

2. way

--- Quote ---at capture-time (db-data will be changed to his native language)
--- End quote ---
When a genre-term should be imported/inserted
the program has just to checkout before insert/update
if there is a replace-term for this genre-term
if there is one found matching the currently used language and the genre-term
the genre-term will be replaced otherwise not
again depending on user-preferences this part will be skiped at all too

thats all

so i do it a 3.way afterwards
at the moment I do this replacment via SQL-Statments
means by example, I replace one genre-ID with an other one matching my needs

anyway, it was just an idea, which came up to my mind
Who this work might be done easy?
so I thought it might be not that much work
but I do not do the job


--- Quote ---3. Setting up these replacements will be time consuming
--- End quote ---
this would be my job I  asked for ;D

thx again for your response
cu meriator

rick.ca:
Maybe this would work okay for some languages, but not for English. The English language is so messed-up, translating by word replacement is a waste of time. There are too many situations where the correct translation depends on the context. Ambiguities could be dealt with for finite word sets like genres, but not for things like categories. It's not uncommon that a word in English will have a significantly broader or narrower meaning than it's most obvious translation in another language. As a result, a direct replacement translation will be correct most of the time, but sometimes incorrect or even misleading. If in a sentence, this still may be acceptable, because the reader can understand the correct meaning from the context of the sentence. But if it's just the word alone or in a short phrase, this is not possible.

I can't comment on the quality of non-English movie information sites, but surely there are some where the quality of the information is reasonably good. By that, I mean the information is properly expressed in the language of the site. It has been subject to some form of competent editing. That might even include doing proper translations where the source of the information is not in the native language. No matter what the language, the quality of the information is only going to be degraded by translating it. I think PVD should remain focused on providing the tools necessary to pull together information from a variety of different sources—while preserving the integrity of that information.

I think the next step, should the development time ever become available, would be to make the program multilingual, rather than attempt to "build-in" translation. Maybe I'm wrong, but I suspect a user who is fluent in English, German and Russian, for example, would be more interested in having their data those languages simultaneously, rather than translating different sources into one language.

I understand that even if one agrees with this point of view, translation of some information is still likely necessary or useful. I think this need would best be served by a translation tool/plugin that uses something like Google Translate, if that is possible. It could take the data from an existing field, translate it, and put the translation in a different field or overwrite the original—according to how it's configured. I don't imagine this would be a very efficient way to translate a large number of fields (e.g., the default set of data from IMDb), but it would be handy for grabbing bits of data only available from a foreign-language site.

meriator:
Oh sorry
my intention is not to translate whole sentences
like description, or taglines
this is sure not possible
I'm talking about single terms like genres, or countries
but also tags as they are simple expressions

one reason is
if I search for a comedy I will find
comedy but not Komödie (german) or comédie (french) or comedia (spanish)
but all mean the same thing
but if Komödie, comédie, comedia will point out to comedy
I will find everything I did searched for

cu meriator

nostra:
I get your point, meriator and, to be honest, I would need this feature as well, but I am not sure if I can put it to 0.9.9 as there are already too many items in my TODO list for this version.

I have this feature request on my list and will implement it as soon as possible.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version