[Feature] support disable repository programing language Detection

[ddatsh]

as title

[lafriks]

Any reason/use case on why?

[guillep2k]

Related: #7953

[lunny]

@lafriks Because they have small memory and don't think this feature is necessary. but have many big repo. And this feature spend many memory.

I also think this feature is just useful for public gitea instances or big enterprise gitea instances.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

[lunny]

Related: #7953

No. That's not the same case. One is for UI language and this one is for repositories' programing languages detection.

[dahrens]

Because I have a typescript project that uses yarn for dependency management: my programming language is now YAML - since yarn.lock is usually huge :)

Ignoring specific files might also solve this.... Of course this is completely negligible...

[silverwind]

Should be per-repo. I think supporting the linguist gitattributes is a good idea which probably makes this an upstream issue.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

[6543]

upstream issue: src-d/enry#18 go-enry/go-enry#27

[silverwind]

Copying my info from the other issue:

---

linguist supports various gitattributes to affect the language stats, I think we should too.

• linguist-generated or maybe just generated for generated code
• linguist-vendored or maybe just vendored for vendored code

Both have the effect that matching files will be excluded from language stats. There's more but I think these two are the most commonly used ones.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

[yurenchen000]

Any reason/use case on why?

Sometimes it gets wrong language,
maybe it is better to manually specify the value or disable it than the wrong value

[delvh]

You can use the .gitattributes to configure what file (type) gets what highlighter.

[yurenchen000]

You can use the .gitattributes to configure what file (type) gets what highlighter.

@delvh
thanks for your reply.

I want to Specify or Disable the language type here (in Repositories list page)
I wonder if this is possible?

[delvh]

Ah, you mean the global one.
Hmm…
Does https://github.com/github/linguist/blob/master/docs/overrides.md perhaps help?
I think -linguist-detectable or linguist-documentation sounds promising.

[yurenchen000]

@delvh
Thanks for your patience, I'll try this doc.

I temporarily use sql to modify the database:

-- change one language in a repo
update language_stat set language='Markdown'  where id=THE_ID;

//this seems not right way. it's Repositories's languages and ratio info

[silverwind]

I doubt we support all linguist-* attributes yet, but we do at least support some like linguist-language and linguist-vendored.

[King555a]

Are there any plans to support linguist-documentation in .gitattributes?

[silverwind]

I'm not up to date where these linguist attributes are currently supported (e.g. gitea vs. go-enry dependency), but there might be a dependency on getting it in go-enry first:

go-enry/go-enry#27

[silverwind]

linguist-language is supported since a while ago.

[github-actions]

Automatically locked because of our CONTRIBUTING guidelines