starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Strings with plural forms #9873

New Issue
Closed
opened 2025-12-29 21:23:47 +01:00 by adam · 6 comments
adam commented 2025-12-29 21:23:47 +01:00
Owner
Copy Link

Originally created by @afranke on GitHub (Jun 19, 2024).

Proposed Changes

In netbox/dcim/choices.py, there’s this bit of code:

83:        (WIDTH_10IN, _('{n} inches').format(n=10)),
84:        (WIDTH_19IN, _('{n} inches').format(n=19)),
85:        (WIDTH_21IN, _('{n} inches').format(n=21)),
86:        (WIDTH_23IN, _('{n} inches').format(n=23)),

That is problematic for translations to some languages, because plural forms don’t necessarily work the same as English where there one and many and that’s it. For instance, in Polish, the word for inches will be declined differently for 21 and for 23, because they end in 1 and 3 respectively and that has an impact.

Considering it’s exactly four specific values and not just any arbitrary value for n, I would suggest just hardcoding the four strings ("10 inches") as translating these four strings will be the most straightforward across languages, and it’s only four strings.

Justification

See plural forms for more details.

I am not suggesting the use of ngettext here because we don’t need a general solution and it would make the code unnecessarily complex here.

Originally created by @afranke on GitHub (Jun 19, 2024). ### Proposed Changes In `netbox/dcim/choices.py`, there’s this bit of code: ``` 83: (WIDTH_10IN, _('{n} inches').format(n=10)), 84: (WIDTH_19IN, _('{n} inches').format(n=19)), 85: (WIDTH_21IN, _('{n} inches').format(n=21)), 86: (WIDTH_23IN, _('{n} inches').format(n=23)), ``` That is problematic for translations to some languages, because plural forms don’t necessarily work the same as English where there one and many and that’s it. For instance, in Polish, the word for inches will be declined differently for 21 and for 23, because they end in 1 and 3 respectively and that has an impact. Considering it’s exactly four specific values and not just any arbitrary value for n, I would suggest just hardcoding the four strings (`"10 inches"`) as translating these four strings will be the most straightforward across languages, and it’s only four strings. ### Justification See [plural forms](https://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html) for more details. I am not suggesting the use of ngettext here because we don’t need a general solution and it would make the code unnecessarily complex here.
adam added the pending closurestatus: under reviewtype: housekeepingnetbox labels 2025-12-29 21:23:47 +01:00
adam closed this issue 2025-12-29 21:23:48 +01:00
adam commented 2025-12-29 21:23:48 +01:00
Author
Owner
Copy Link

@afranke commented on GitHub (Jun 19, 2024):

"Group {n}" in netbox/vpn/choices.py is in a similar situation and I understand that you are trying to create less work for translators, but this is actually going to create problems instead of solving them. Please just do one string per number. The extra strings will be easy enough to translate with minimal overhead.

@afranke commented on GitHub (Jun 19, 2024): `"Group {n}"` in `netbox/vpn/choices.py` is in a similar situation and I understand that you are trying to create less work for translators, but this is actually going to create problems instead of solving them. Please just do one string per number. The extra strings will be easy enough to translate with minimal overhead.
adam commented 2025-12-29 21:23:48 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 21, 2024):

Please just do one string per number. The extra strings will be easy enough to translate with minimal overhead.

I'm not sure I agree. At point do you think it becomes unreasonable? Ten unique strings? A hundred? It would be unfair to put that burden on translators if it can be minimized via the use of ngettext().

@jeremystretch commented on GitHub (Jun 21, 2024): > Please just do one string per number. The extra strings will be easy enough to translate with minimal overhead. I'm not sure I agree. At point do you think it becomes unreasonable? Ten unique strings? A hundred? It would be unfair to put that burden on translators if it can be minimized via the use of `ngettext()`.
adam commented 2025-12-29 21:23:49 +01:00
Author
Owner
Copy Link

@ITJamie commented on GitHub (Jun 22, 2024):

This is always a PIA when dealing with translations. The same problem happens when dealing with strings like 1st,2nd,3rd etc as many languages have different rules for this and can impact other parts of the string, not just the "counter" part.

A few enterprise products i work with handle this by having "primary" and "fallback" versions of the same string (or even fully parsed vs templated versions of the string)

So the translation code first calls the more specific/fully parsed version of the string (eg "10 groups"), if that is not found it then falls back to "{N} groups" lookup, that allows languages which have more complicated phrasing to have specific overrides for handling declension an conjunction rules.

It also allows for translations to still quickly get built and overrides added in future for specific issues. Since by default you wouldn't request translations of "10 groups" you'd only request translations of "{N} groups".
Only languages which need extra declension/condjuction rules would get these "overrides" added to their language files.

@ITJamie commented on GitHub (Jun 22, 2024): This is always a PIA when dealing with translations. The same problem happens when dealing with strings like 1st,2nd,3rd etc as many languages have different rules for this and can impact other parts of the string, not just the "counter" part. A few enterprise products i work with handle this by having "primary" and "fallback" versions of the same string (or even fully parsed vs templated versions of the string) So the translation code first calls the more specific/fully parsed version of the string (eg "10 groups"), if that is not found it then falls back to "{N} groups" lookup, that allows languages which have more complicated phrasing to have specific overrides for handling declension an conjunction rules. It also allows for translations to still quickly get built and overrides added in future for specific issues. Since by default you wouldn't request translations of "10 groups" you'd only request translations of "{N} groups". Only languages which need extra declension/condjuction rules would get these "overrides" added to their language files.
adam commented 2025-12-29 21:23:49 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Sep 21, 2024):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Sep 21, 2024): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 21:23:49 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Oct 21, 2024):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Oct 21, 2024): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
adam commented 2025-12-29 21:23:49 +01:00
Author
Owner
Copy Link

@afranke commented on GitHub (Dec 2, 2024):

At point do you think it becomes unreasonable? Ten unique strings? A hundred? It would be unfair to put that burden on translators if it can be minimized via the use of ngettext().

Doing nothing clearly isn’t better. I offered two options: hardcode the 24 Group {n} strings (really not a big deal, even if you disagree, considering how trivial the strings are) or use ngettext. If you actually care about translators, worry less about the burden and worry more about providing workable material.

@afranke commented on GitHub (Dec 2, 2024): > At point do you think it becomes unreasonable? Ten unique strings? A hundred? It would be unfair to put that burden on translators if it can be minimized via the use of `ngettext()`. Doing nothing clearly isn’t better. I offered two options: hardcode the 24 `Group {n}` strings (really not a big deal, even if you disagree, considering how trivial the strings are) or use `ngettext`. If you actually care about translators, worry less about the burden and worry more about providing workable material.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label netbox pending closure status: under review type: housekeeping
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#9873
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?