关于三个CVS文件的作用和分类

[scj008]

标准文件CVS（标准.cvs）,
翻译文件CVS（翻译.cvs）,
附加内容CVS（附加.cvs）,
现在的问题描述：首先，我觉得翻译的引入，是这个插件非常大的亮点。但现在的问题是，不管你在“标准.cvs”还是“附加”里添加自己的内容，都需要打开“翻译.cvs”来补充内容，

示例：
我们在“附加.cvs” 根据规则（“name”,“type”,“postCount”,"aliases"）
添加 <User_Test_Document>,<5>,<"测试文档1">,<"测试文档2">

我们虽然能通过 别称（aliases）-“测试文档2” 搜索到中文的标签，（但我明白，你因为文件大小的原因，不能把别称在下面显示出来。）

如果我们要做到这一点，必须要在“翻译.cvs”里添加这样的内容。才能达到我们需要的效果！！下面的提示框 对于之后的修改真的是太有用了。
<User_Test_Document>,<测试文档1>

建议：
为了更好的达到这一个效果，我们在每次加入新词的时候，就必须要打二个文档来进行编辑。这很不友好。并且“附加.CVS”里有数量标签显然是浪费的。并且通常我们在加入到附加文件里的内容都是我们自建的，其实另名对于我们也相对并不是重要，但为了防止我们之后不断的要加入新的词。我的建议是，重新指定“附加.CVS”这一文件的引入规划，
将原来的（“name”,“type”,“postCount”,"aliases"）
更改成为（“name”,“type”,“aliases”,"Translations"）
但是最终的结果就是为了更好的，在添加自定义词的时候更方便。

@@因为语言的问题，我尽量的把想要表达的描述清楚。@@
我对多的把提示框的功能变更成了翻译的功能。可能我对于该插件的主体功能产生了偏移，但我想让你明白，这个插件真的非常优秀。谢谢。

[DominikDoom]

这是个合理的建议。有一个问题是，我不想取代 "数量标签"，因为这一栏不是为了在额外文件中的帖子数量，而是为了给你的新条目添加一个类别。例如，在默认的额外文件中的 "质量标签"。所以只是作为一个有用的视觉帮助，将其与普通标签区分开来。然而，我们可以在最后添加翻译行。因为文件是单独加载的，我们可以只添加它，如果它在那里，否则忽略。所以 name,type,category,aliases,translations。

这也许会导致一些重复的功能，因为正常的翻译文件仍然存在，但我同意，对于小套的额外标签来说，在同一个文件中进行翻译是一个有用的生活质量特征。

用这种方式，如果没有别名，格式可能看起来有点奇怪，但程序解析起来没有问题，例如 User_Test_Document,5,测试文档1,,测试文档2。(请看空栏，一个逗号直接跟在另一个逗号后面)

[DominikDoom]

我在 dcc6602 中实现了上述内容，希望对你有用。

[scj008]

非常荣幸，你为我解决这个问题。
我现在就去测试。希望你不要介意，我再次的向您提出问题。同时我觉得我可能还会经常的会来打扰您的。希望你不要介意。
又是愉快的一天。谢谢。

[scj008]

我升级了你的文件以后，发现在正面提示词和反向提示词中间不能正确的显示 已经完成的翻译内容了？我尝试了很多次，都没有成功，是因为版本的问题吗？

[scj008]

翻译和显示都很正常，就是正面提示词和反向提示词之间的保留内容没有了。
我尝试换回之前的我电脑中保留版本是正常显示的。（但我不确定，我留下的版本是你文件里的几号版本了。）

红色框那一部分显示 不正常了。目前我仍在尝试修复这个问题。

[DominikDoom]

啊，我想我现在明白你的意思了。提示下方的永久翻译来自一个分叉（https://github.com/inlhx/a1111-sd-webui-tagcomplete-10w, 我想）所以该分叉的维护者将不得不更新以包括我最近的修改。在这一点上，这个功能在这里没有计划，因为它对非中国用户来说是非常小众的。

[scj008]

在此之前，我合并了你们的一些功能，我现在正在试图，从你们二个人的文件中找出最优的解决办法。
很显然红框部分对于英文并不好的人来说，有了这个红框对后期的修改提示词是非常非常方便的一个办法。但我好像又非常的确定你之前的版本里的确有过这样的功能。
另外：
开个玩笑，我不知道你们那边现在是几点了，为什么你还没有休息，嘻，我们这边是03：30分。也许是我太激动了。

[DominikDoom]

哈哈，别担心，对我来说还没那么晚，刚吃完饭。
不，这种类型的永久翻译从来都不是这个版本的代码的一部分。我可以看到它是非常有用的，但它有点超出了范围。这个扩展真的只是为了自动完成标签，而这样的功能在独立的翻译扩展中会更适合。有点遗憾的是，分叉的创建者选择了修改整个项目，而不是创建一个与这个项目一起工作的不同扩展，因为这意味着变化并不总是同步的。

但我将在周末看看我是否能自己创建这样一个独立的扩展，或以更优雅的方式修改这个项目。

[scj008]

没错，从理论上来说，https://github.com/butaixianran/Stable-Diffusion-Webui-Prompt-Translator 这样的翻译功能兴许对于一个翻译插件来说，更智能，至少他的词库不是手工建立的。
但你不知道你这个插件我们这个圈子里或者国内有多受欢迎 ，他们很更热忠你这个功能（当然我是忠实的死粉。哈哈。），因为真的太方便了，对于翻译软件来说，他有很多的词并不是MODEL的标准TAG，但你这个能很好的解决这个问题。
至少我会经常从别人那里得到或者自己添加一些自己经常用的非常有效的TAG到这个库中。（但我不会无脑的加到10万这个这么疯狂的程度，我更希望他们是高效的，并且是有效的。）

我在第一次的讨论里也表达了，我对该问题的理解。
///我对多的把提示框的功能变更成了翻译的功能。可能我对于该插件的主体功能产生了偏移，但我想让你明白，这个插件真的非常优秀。谢谢。///
但我更希望，你这个插件能多一项非常棒的功能。而且这个真的真的很受用，我们这边的视频博主，几乎是人手一份的在使用你的插件。

也许对于中文的习惯和用法上，我们存在一定的习惯偏差。看到你解决问题的8行代码，我已经在深思了。哈哈。
但我并不想给你增加太多的麻烦。

[scj008]

我好像通过自己的努力，解决了，哈哈，同时佣有了你们的功能，当然更期待你对该功能的优化方案。

[DominikDoom]

我今天做了一些工作，我想我已经得到了一个好的结果。你觉得这个用于现场翻译的用户界面演示如何？
它使用特殊的HTML注释元素，例如用于拼音的注释元素。

(不同的颜色是为了便于阅读，因为否则很难看出哪些文字是属于一起的）
我很满意的一点是，如果没有找到直接的匹配，它甚至能够找到包含在更大文本中的两个或一个单词的组合，即使没有逗号。

作为一个不懂中文的人，我不确定这样显示的汉字是否太小。我想过把它们调换一下（所以英文标签在中文上面），但这使得它更难与文本框进行比较。你怎么看？

[scj008]

时差的原因，我现在才看到你的内容。
当看到【pretty girl sitting in a flower field during sunrise (坐着 花田 日出)】的时候，我觉的这个想法，真的太完美了。

关于界面的优化，我想提几点我的想法，希望对你参考的作用。
一、字体大小：既然我们下面这行的作用就是为了方便母语阅读，那么，中文的突出显示我个人觉得更加重要，（中文字符串大于英文，便于阅读，英文只用于对应功能。）
二、对齐方式：因为中文-英文字符 需要做到完全长度的相等，我觉得很强，而且在很多时候，我们会用比较长的翻译内容来做一些标注以便于搜索，
那我觉得对齐的方式，使用前端对齐会更加的理想。

三、 这样做的好处还有，仅以当前词组，我们会得到更加短的提示框。

四、不成熟的想法和建议，对于UI，我们其实并不希望在界面上出现过多的颜色，这样会显的很杂乱。所以我在考虑，是否只保留英文的颜色区分，用于区分我们的类别，（你在分类上已经做了很多工作，我觉的这真的是一个非常好的想法。）

以上是我对界面类的一些建议，非常开心能让我一起参与到主个项目中来。非常荣幸

[scj008]

对于功能上的补充说明，我有一个想法，同样是因为语言的不同，我尽量描述的复杂一些，希望你能明白。
当我们需要对相应的词进行替换的时候，（这个功能我觉得对于英文也相当的友好）
1、鼠标点击，移动到我们想要替换的词组前。

2、我们会在固定的位置出现一个临时的文本框，

3、输入我们想要替换的内容，

4、一切又好像没有来过一样，当然TXT2IMG里的内容也是需要替换的。

[scj008]

补充：
1、需要注意的问题，他不需要太快的刷新率，因为当我们从别的地方复制咒语过来的时候，它会很长，如果在那个阶段我们就把翻译的过程界入，可能会很卡。所以我更建议，完成双击，失去热点的时候，我们再进行一次翻译及更新。这样会更方便。

[scj008]

后期我会协助你更新一份，比较完整及有效的中文内容，供你提供分支使用或者下载使用，
其实对于功能，我还有一些小的建议，越来越复杂了。
哈哈。因为每个模型的提示词是不同的，我觉得是否可以针对于相对于流行的模型加入定量的相对有效的提示，不是所有的模型都只适用于1GIRL的。哈哈。
我们能否针对于模型在提示的时候，会有针对性的建议，当然这个可以在我们做提示词的时候，加入别名来重点做区别。（但需要把这个好的经验分享出来。）

[DominikDoom]

我已经尝试实施你的一些建议：

replace_demo.mp4

正如你所看到的，点击会选择提示的相关部分，所以你可以通过打字立即替换它。
在我的系统上，翻译速度非常快，所以为了方便开发，我暂时把它作为一个实时更新。但我以后可能会改变它。

还有一些错误和缺失的功能，以及我今天没有时间做的事情，比如使用现有的分类颜色。所以我还没有把它合并，但你可以通过查看这个分支来尝试：https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/tree/feature-rubytext

关于你的最后一个建议，即使用特定型号的标签，这是很难做到的，因为没有中央模型数据库来保存这些信息。手动操作也许是可能的，但似乎非常乏味。
因此，把这些信息的组织工作留给用户可能会更好，就像现有的元素法典之类的法术书一样。或者直接使用webui的"Styles"功能，保存效果好的部分，以便以后重复使用。

[DominikDoom]

顺便说一下，我修复了最后的一些东西，使其与当前的主版本一起工作，并在刚才将其合并。所以现在你可以把它和其他最近的修复和增加的内容一起享用。你可能必须重新启用它，因为它默认为关闭。

[scj008]

我已经在测试你的新版本了，非常感谢！

[scj008]

大神，好久不见。单纯的打个招呼。看到你一直在升级版本，真的太敬业了。“其实我不知道如何单独的给你发送消息。”：）

[DominikDoom]

哈哈，谢谢！我觉得私信也不是这里的特色。

我认为一个重要的激励因素是，我自己也经常使用它，将其作为一种业余爱好。最近的大多数功能都是因为我对没有这些功能的工作流程感到恼火。

[scj008]

目前我们中国比较流行的一些提示工作，都在你的基础上更新了，而且我看很多想法也都基于我们讨论的逻辑，嘻。嘻。供您参考。
希望你越来越好。当然我一直还在使用您的版本，我觉的这个版本的可控性是最高的。
但分组的标签的逻辑倒也不失为一个好的方向。但他生成的效率太低了。
https://github.com/blue-pen5805/sdweb-easy-prompt-selector
https://gitee.com/physton/sd-webui-prompt-all-in-one

[FCJ1987]

首先非常感谢作者制作了这个插件，同时也感谢楼主提供的这个讨论帖，这个讨论帖中的内容解决了之前困扰我的一些疑惑。
虽然问题已经解决了，不过我还是多嘴说几句个人感受。因为我没有专业的编程知识，所以我的一些理解可能会存在偏差。但是，鉴于大多数人应该也像我一样并没有很专业的编程知识，而我之前所困惑的问题在中文网上几乎没有找到什么有效的解答资料，所以还是斗胆在此抛砖引玉，或许能对后来看到的人有所帮助。当然，如果我的理解和表达的内容有什么疏漏的地方，希望不要对任何人造成误导。

因为我甚至都不是一个二次元爱好者，在接触到本插件之前，我都不知道booru是什么。所以最初我很难理解CSV词库文件的格式和它们的数据含义。后来我发现booru类图床网站对图片TAG信息的标记和整理是如此的详细，我这才模糊的意识到danbooru.SCV文件中的各种格式所代表的意义。我猜测因为要用Python之类的工具从booru类网站API接口上爬取TAG信息，为了符合这套自动化流程，所以danbooru.SCV天然的要符合booru网站自带的TAG信息的一些格式。而添加自定义提示词和从译名查找提示词的需求是后来才提出的。同时，因为添加的自定义提示词和译名这个属性是booru网站上并没有的信息。所以自定义提示词和译名这两个属性无法匹配原来danbooru.SCV文件的格式。所以我们现在可以看到作者在“danbooru.SCV”（标准词库）之外另外增加了两个内容：”extra.SCV（额外词库）"和“danbooru_zh.CSV（翻译词库）”。在明白了这一切是怎么来的之后（如果我没理解错的话），我对这一套工作流持双手赞成的态度。因为我觉得随着网站数据的更新，danbooru.SCV的文件未来很有可能是会修改、扩增的。而修改后的文件肯定还是以Python之类的形式自动化更新的，如果直接对danbooru.SCV做手动修改，那未来更新的数据就不能简单的以覆盖原有danbooru.CSV的方式更新了。虽然也不是不能用补丁更新之类的方式解决，但是毕竟“如无必要，勿增实体”。
如上所述，我觉得基于方便未来自动化更新的流程考虑，“标准.SCV”和“翻译.SCV”都不应该手动修改内容。“标准.SCV”是从danbooru上自动爬取的内容，而“翻译.SCV”是对“标准.SCV”内容的镜像复制和翻译，这两者都是为了以自动化的方式高效的爬取/自动翻译一个庞大的提示词数据库，而少量手动修改的自定义内容不应该在这两者中处理。
所以在”extra.SCV（额外词库）"中在增加自定义提示词的同时也能提供翻译的格式是有必要的。当然现在作者已经解决了这一问题。不过，既然自定义提示词是每个使用者自己增加的，那这些自定义提示词显然就没有booru上的相应信息吧，那我是否还需要严格遵守为了匹配booru而设置的格式呢。比如在aliases别名这一栏，可以直接写译名吧，反正别名译名都能搜索到提示词。而“postCount”点击数这一项，与其让他空着，为什么不干脆当成补充注释项来写呢。除非这些项目还涉及到其他规则，比如假设“postCount”点击数如果根据数值大小，会影响到提示词推荐的优先级之类。否则的话，应该可以对额外.CSV的相应格式按自己的需求重新诠释吧，只要最后使用的时候操作逻辑和体验能符合自己的预期就行。

[DominikDoom]

你的总体理解是正确的。虽然 csv 文件的格式是当时随意选择的，但因为 danbooru API 数据的格式完全不同。我只是选择了最有用地列并将其导出到 CSV 文件，以减小文件大小并提高加载时间。
起初，额外的标签几乎完全相同，因为它们重复使用了与正常标签相同的代码。不过，后来我改变了它们的结构，因为许多用户不小心选择了完整的标签文件，如 danbooru.csv 或 e621.csv。当时，额外的标签会与现有的标签进行比较，因此如果列表过长，加载时间就会因为多次检查而成倍增加，通常需要好几分钟。
由于它始终只适用于小的自定义标签，如包含的质量标签，因此我删除了比较功能并简化了格式。它们根本不会被排序，只是在匹配的情况下添加到搜索结果的其他部分之前，因此上一篇文章计数列变成了提示文本的一般 "元 "列。
当然，在列的数量和颜色的类别规格等方面仍有一些相似之处，但在代码中，它们的处理要比完整标签简单得多（例如，完整标签确实是按帖子数量排序的）。

后来，由于这个讨论主题，处理翻译的方式也有所改变。理论上，您可以将它们添加为别名，但现在它们也有自己的列附加在最后。我之前在讨论中提到过，目前的格式是：标签、颜色、提示文本、别名、翻译。
如果前一列没有数据，只需在其后直接添加下一个逗号即可跳过，无需写入任何内容。

如果您想添加较长的自定义预置，我建议您使用 "Chants" 功能。很遗憾，中文自述已经过时，但你可以尝试用软件翻译其中的英文部分。https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/tree/main#chants

[FCJ1987]

好的，我之前已经注意到中文自述似乎比英文的要少一些内容了。不过比起语言的隔阂，对我来说更困难的是我难以理解文档中的很多技术内容。

比如虽然文档中已经说明了CSV的格式是 ,,,""，但是在接触到danbooru之前，我完全不知道其中的type和postcount是什么意思，对着1girl,0,4114588,"1girls,sole_female"的案例模仿，却不知道该在,,这两列里填什么内容。需要添加自定义提示词的时候，不是直接把提示词添加进“danbooru.csv”中因为格式错误导致插件失效，就是把提示词添加到“翻译.SCV”文件里却并没有出现增加的提示词。虽然现在来看这都是些非常基础，简单到不需额外说明的内容，但是此前我就是受此所困扰。而几乎全网对本插件的视频介绍，都是简单演示了一下安装和输入时自动补全提示词的操作。没有一个视频有对作者自述文档的解读的。

我看到过有一个视频UP主介绍了一个做法：他在设置中把标准.CSV、翻译.CSV、额外.CSV三个位置全加载成了翻译.SCV，当需要添加自定义提示词或者添加翻译的时候，他只修改翻译.CSV。虽然因此丢失了,之类的booru信息，但这已经是我看到过唯一能解决添加自定义提示词和添加翻译而不会引起格式错误导致插件失效的中文网视频了，那个视频下面是一大群对此报以赞赏以及依然出现格式错误而准问不休的评论，而我也是其中之一LOL

目前来说，这个插件的wildwords通配符的用法，chants功能，第三方插件的激活等功能我还不是很明白，包括启动时出现的错误提示“could not locate model-keyword extension...”，虽然您已经回复过：“...这是提示该扩展的一项功能，即支持基于外部列表的 Lora 关键字补全。它需要另一个扩展。但如果没有它，插件也能正常工作...”，但我也还是好奇这个“外部列表lora关键字的补全”是什么意思，需要的另一个扩展是不是这个 (https://github.com/mix1009/model-keyword)

总之需要进一步弄明白的东西还有好多，等我解决了它们（也许吧），我或许应该写篇文章或者做个视频，把我收到帮助解决的这些问题，再详细的解析和传递给其他人。

[DominikDoom]

是的，肯定有某种类型的功能蠕变，而且大多数外部资源跟不上变化。英文文档已经相当完整，但其他语言的文档还有些滞后（就中文而言，滞后很多），因为我依赖于社区的帮助。当前自述文件的篇幅使得全部用机器翻译是不可行的，或者至少在验证正确性时非常麻烦。
由于大多数模型只知道原始的 danbooru 标签，因此从未考虑过更大的自定义标签集。 但是，使用当前方法，应该可以保留原始标签集中的所有内容，并使用其他两个文件添加具有正确翻译的新附加内容。 至少只要它没有大到需要排序。
但作为普通用户，您实际上只需要包含的文件和预制的社区翻译文件之一。

至于model-keyword：
一些 Lora 需要激活关键字，因为它们是根据这些关键字进行训练的。 特别是对于 Lora 添加新字符，仅添加 lora:___:1 提示符修饰符本身通常是不够的。 他们还需要角色名称、服装标签或其他唯一标识符。

在当前的 WebUI 版本中，您可以通过单击 Lora 卡上的右上角按钮，然后将它们输入到此文本框中来自行添加这些关键字：

如果您使用自动完成功能以及键入 < 或 <l: 时显示的列表来完成 Lora 名称，如果在设置中激活它，它会将它们添加到提示中：

该方法始终可以在没有任何其他扩展的情况下工作，但需要手动添加这些关键字。

https://github.com/mix1009/model-keyword 是一个定期更新的离线列表，可以从 Civitai 中抓取关键字。
大多数作者都会添加他们的 Lora 需要的关键字，因此即使用户自己没有手动添加它们，扩展程序也可以尝试填充这些关键字。
要在 tag-autocomplete 中使用此本地列表，需要安装扩展以便文件存在，但不需要在 webui 中激活。
这只是常规功能集的补充，如果您有很多具有不同触发关键字的 Lora（没有人能记住那么多，2333），这会非常有用

[FCJ1987]

好的，非常感谢，我会去实践一下的。