Skip to content
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

Translation not working #62

Closed
byzod opened this issue Nov 4, 2022 · 7 comments
Closed

Translation not working #62

byzod opened this issue Nov 4, 2022 · 7 comments

Comments

@byzod
Copy link

byzod commented Nov 4, 2022

  1. Download 82355cd as zip, extract to sd webui's extension folder \extensions\tag-complete\
  2. Create test.csv with content below and save with UTF-8 encoding, place it into \extensions\tag-complete\tags\
    solo,0,单人
    
  3. Change line 24 of \extensions\tag-complete\tags\config.json from "extraFile": "", to "extraFile": "test.csv",
  4. Launch sd webui and wait for tagcomplete loaded, then type sol in prompt textbox

Expected result:

0

Actual result:

1

@DominikDoom
Copy link
Owner

The translations will only show if you search by the translated term, just with the rest of the aliases.
So in case of this example, it will show when typing a part of 单人.

I can't really have an "always show" option since a tag often has multiple aliases, so there's no way to choose which one to display in that case (except maybe defaulting to the first/last). And I also don't want to add a completely separate field for translation in the csv since aliases and translations are functionally the same.

Is this a big issue? I was under the impression that you would only use the translations by typing the translated term in the first place.

@byzod
Copy link
Author

byzod commented Nov 5, 2022

The translations will only show if you search by the translated term, just with the rest of the aliases. So in case of this example, it will show when typing a part of 单人.

I can't really have an "always show" option since a tag often has multiple aliases, so there's no way to choose which one to display in that case (except maybe defaulting to the first/last). And I also don't want to add a completely separate field for translation in the csv since aliases and translations are functionally the same.

Is this a big issue? I was under the impression that you would only use the translations by typing the translated term in the first place.

Yes, it's a game changer. Searching english words while displaying translation is the main feature required for non-english speakers, just like the main input box for English-Chinese translation requires you type english words, not the contrary. Or like physical english dictionaries, there're no dictionaries indexed by Chinese words

Search Chinese to find english result is an excellent additional feature but not essential. Just like chinese-english translation, they have different purpose and can't replace each other's role

I suppose that different implementation of alias and translation is required, they're not exact the same thing

Translation with alias could possible looks like this:
3

or this:
2
(by using ruby text)

@DominikDoom
Copy link
Owner

I changed it to work like in your first suggestion for now. Translations need to be added in a new separate CSV file, not as an extra file anymore. Default is just two columns with English as first and Translation as second, but I also included a config switch for the old extra format with 3 columns if you use one of those files.
The translations are currently always visible, and are matched purely based on the tag/alias name. Searching by the translated text still works like before if you leave it true in the config.

@byzod
Copy link
Author

byzod commented Nov 5, 2022

I changed it to work like in your first suggestion for now. Translations need to be added in a new separate CSV file, not as an extra file anymore. Default is just two columns with English as first and Translation as second, but I also included a config switch for the old extra format with 3 columns if you use one of those files. The translations are currently always visible, and are matched purely based on the tag/alias name. Searching by the translated text still works like before if you leave it true in the config.

Thanks! This is really important for who using it as translate tag helper

@byzod
Copy link
Author

byzod commented Nov 6, 2022

@DominikDoom

  1. I found that search results by translated text is much lesser than before with the same translation csv, for example searching , every sorts of socks/stocking/thighhighs are displayed, in fact there are 121 hits of in translation csv
    But after 1.11 I got only 16 results no matter what, even I change resultStepLength to an absurd high value

    demo of searching results of with abb5625
    1

    screenshot of searching results of with 4eabf00, step length 95500
    2

  2. Strangely, in 4eabf00, 美式短袜 (bobby_socks) is in results when searching 短袜 but is not when searching . Few test results: (test done with step length 500 cuz 95500 is too laggy...)

    searching terms bobby_socks[美式短袜] included in results
    Yes
    No
    No
    No
    美式 Yes
    式短 Yes
    短袜 Yes
    美式短 Yes
    式短袜 Yes
    美式短袜 Yes

Translation and config I use, if it helps (filename with -legacy is for pre-1.10)
cn tags test.zip

p.s. not sure if this is the same problem, should I open a new issue?

@DominikDoom
Copy link
Owner

You're right, I tried it with your translation file and it seems to be a bug related to if the searched translation is in the alias, but not the tag itself. The example with bobby_socks is caused because the results with e.g. 式 include tags where this is the case, so the list is cut off on the first tag that fails to match (in this example "ascot").

@DominikDoom
Copy link
Owner

I think I was already able to fix it, at least I don't see any more cutoff on my side with your test tags.
But feel free to reopen this if you find something that still behaves strange with translations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants