starred/karakeep

Fork 0

mirror of https://github.com/karakeep-app/karakeep.git synced 2026-04-25 16:06:04 +03:00

[GH-ISSUE #1578] FR: Disallow case sensitivity in tags #983

New issue

Open

opened 2026-03-02 11:54:09 +03:00 by kerem · 6 comments

kerem commented

2026-03-02 11:54:09 +03:00

Owner

Originally created by @sprior on GitHub (Jun 9, 2025).
Original GitHub issue: https://github.com/karakeep-app/karakeep/issues/1578

Describe the feature you'd like

When importing my bookmarks it appears that the AI will commonly suggest a tag in both all lowercase and with the first letter capitalized and karakeep seems to be creating tags for both. While I'm sure there's someone out there who wants case sensitive tags it probably isn't what most people want.

I'd suggest making bookmark tagging use a case insensitive check to make sure that tag doesn't already exist before creating a new one and if it does use the existing one instead.

Describe the benefits this would bring to existing Karakeep users

It'll avoid LOTs of tag clutter.

Can the goal of this request already be achieved via other means?

not that I'm aware of

Have you searched for an existing open/closed issue?

I have searched for existing issues and none cover my fundamental request

Additional context

No response

Originally created by @sprior on GitHub (Jun 9, 2025). Original GitHub issue: https://github.com/karakeep-app/karakeep/issues/1578 ### Describe the feature you'd like When importing my bookmarks it appears that the AI will commonly suggest a tag in both all lowercase and with the first letter capitalized and karakeep seems to be creating tags for both. While I'm sure there's someone out there who wants case sensitive tags it probably isn't what most people want. I'd suggest making bookmark tagging use a case insensitive check to make sure that tag doesn't already exist before creating a new one and if it does use the existing one instead. ### Describe the benefits this would bring to existing Karakeep users It'll avoid LOTs of tag clutter. ### Can the goal of this request already be achieved via other means? not that I'm aware of ### Have you searched for an existing open/closed issue? - [x] I have searched for existing issues and none cover my fundamental request ### Additional context _No response_

kerem added the

feature request

status/untriaged

labels

2026-03-02 11:54:09 +03:00

kerem commented

2026-03-02 11:54:10 +03:00

Author

Owner

@MohamedBassem commented on GitHub (Jun 15, 2025):

This has been there since April last year, implemented in github.com/karakeep-app/karakeep@b4c7de2ab0

Is it not working as expected? Do you have an example? Feel free to re-open the issue when you have a repro.

@MohamedBassem commented on GitHub (Jun 15, 2025): This has been there since April last year, implemented in https://github.com/karakeep-app/karakeep/commit/b4c7de2ab00fb43a70c984138b79577a65c95191 Is it not working as expected? Do you have an example? Feel free to re-open the issue when you have a repro.

kerem commented

2026-03-02 11:54:10 +03:00

Author

Owner

@sprior commented on GitHub (Jun 15, 2025):

Right now I have in my cleanup suggestions one to consolidate "S3", "s3", and "1960s". Obviously the third one is a totally different thing but the first two differ only in the case of the S. Note that "s3" is in the manual tags section and "S3" is in the AI tags section in case you're not checking across the two.
Ideally I'd like to migrate manual tags in favor of AI tags if possible. I've only been using Karakeep for less than 2 weeks so no chance I've ever used a version before the change you mentioned. I'm in the process of importing 20,000 bookmarks from Pocket using its CSV export.

It says I don't have permissions to reopen the issue.

@sprior commented on GitHub (Jun 15, 2025): Right now I have in my cleanup suggestions one to consolidate "S3", "s3", and "1960s". Obviously the third one is a totally different thing but the first two differ only in the case of the S. Note that "s3" is in the manual tags section and "S3" is in the AI tags section in case you're not checking across the two. Ideally I'd like to migrate manual tags in favor of AI tags if possible. I've only been using Karakeep for less than 2 weeks so no chance I've ever used a version before the change you mentioned. I'm in the process of importing 20,000 bookmarks from Pocket using its CSV export. It says I don't have permissions to reopen the issue.

kerem commented

2026-03-02 11:54:10 +03:00

Author

Owner

@sprior commented on GitHub (Jun 17, 2025):

@MohamedBassem You mentioned reopening if I had an example and I do (see previous comment) but I don't have permissions to reopen.

@sprior commented on GitHub (Jun 17, 2025): @MohamedBassem You mentioned reopening if I had an example and I do (see previous comment) but I don't have permissions to reopen.

kerem commented

2026-03-02 11:54:10 +03:00

Author

Owner

@xuatz commented on GitHub (Jun 20, 2025):

helped to reopened for visibility, but still subjected to @MohamedBassem to triage 🙇

@xuatz commented on GitHub (Jun 20, 2025): helped to reopened for visibility, but still subjected to @MohamedBassem to triage 🙇

kerem commented

2026-03-02 11:54:10 +03:00

Author

Owner

@giacomocerquone commented on GitHub (Nov 29, 2025):

So, by using ollama and generating tags through llama3.1:8b tags gets generated with several different casing (Accessory, accessory, etc).

This wouldn't be a problem for me unless the smart lists query languages would be case insensitive.
That for me is the deal braker when it comes to tags case sensitivity.

This is also to say that the problem should be tackled from a querying perspective and not from the ai generation which should always be considered unpredictable.

Btw I also tried adding the following custom prompt which did not do anything at all: all tags must be lowercase

@giacomocerquone commented on GitHub (Nov 29, 2025): So, by using ollama and generating tags through llama3.1:8b tags gets generated with several different casing (Accessory, accessory, etc). This wouldn't be a problem for me unless the smart lists query languages would be case insensitive. That for me is the deal braker when it comes to tags case sensitivity. This is also to say that the problem should be tackled from a querying perspective and not from the ai generation which should always be considered unpredictable. Btw I also tried adding the following custom prompt which did not do anything at all: `all tags must be lowercase`

kerem commented

2026-03-02 11:54:10 +03:00

Author

Owner

@giacomocerquone commented on GitHub (Nov 29, 2025):

So, I've seen the commit you pointed @MohamedBassem and I think the bug is in the following lines where the code does:

    await tx
          .insert(bookmarkTags)
          .values(
            notFoundTagNames.map((t) => ({
              name: t,
              userId,
            })),
          )
          .onConflictDoNothing()
          .returning()

but notFoundTagNames is defined like so:

      const notFoundTagNames = normalizedInferredTags
        .filter(
          (t) =>
            !matchedTags.some(
              (mt) => normalizeTag(mt.name) === t.normalizedTag,
            ),
        )
        .map((t) => t.originalTag);

the mapping to t.originalTag is where the problem lies. It doesn't insert the normalized one.

@giacomocerquone commented on GitHub (Nov 29, 2025): So, I've seen the commit you pointed @MohamedBassem and I think the bug is in the following lines where the code does: ``` await tx .insert(bookmarkTags) .values( notFoundTagNames.map((t) => ({ name: t, userId, })), ) .onConflictDoNothing() .returning() ``` but `notFoundTagNames` is defined like so: ``` const notFoundTagNames = normalizedInferredTags .filter( (t) => !matchedTags.some( (mt) => normalizeTag(mt.name) === t.normalizedTag, ), ) .map((t) => t.originalTag); ``` the mapping to `t.originalTag` is where the problem lies. It doesn't insert the normalized one.

kerem referenced this issue

2026-03-02 11:58:53 +03:00

[PR #983] [MERGED] feat(i18n): add Arabic language support #1723

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/karakeep#983

No description provided.

Rows
Columns