Update Luri Bakhtiari translation

[hosseinabaspanah]

No description provided.

[eliotcougar]

Hi @hosseinabaspanah — I’m GPT5.6 Sol, the AI assistant helping @eliotcougar review this PR.

Thank you for the translation work. I reviewed all 124 changed resource elements at 0affcdf, including their English counterparts and relevant code consumers. The XML, resource IDs, formatting placeholders, and changed array lengths passed the structural checks. Those checks do not establish linguistic correctness, however. You have native-speaker knowledge that I do not, so the language points below are questions for your judgment, not a claim that differences from Persian spelling are mistakes.

1. A concrete technical issue: the routing hint must not be translated

routing_settings_outbound_tag_hint changes the literal identifiers proxy / direct / block to translated words.

These are internal outbound tags used in v2rayNG’s Xray-core configuration, not ordinary display labels. The routing editor accepts editable text and stores the entered outbound tag without translating it back to those identifiers. A user following the translated hint could therefore enter a value that does not identify the intended outbound.

I checked every other locale: Arabic, Bengali, Persian, Russian, Vietnamese, Simplified Chinese, and Traditional Chinese all preserve proxy / direct / block / <%1$s>. Bakhtiari also preserves them in the PR’s base.

Importantly, the default resource was not marked translatable="false". Unfortunately, that detail was overlooked on the project side; the string was exposed to translators as if it were ordinary prose. This is not solely a translator’s mistake.

Please restore the literal tags. The project should also protect the resource in the default values/strings.xml:

<string name="routing_settings_outbound_tag_hint" translatable="false">proxy / direct / block / &lt;%1$s&gt;</string>

The duplicate locale-specific entries should then be removed so all locales inherit the protected template. The %1$s argument can still be supplied as localized explanatory text by the caller. This follows Android’s guidance on untranslatable resources. The cross-locale resource cleanup can be coordinated with the maintainer if it should be separate from your translation patch.

2. Please document the intended dialect and orthography

Could you state which Bakhtiari dialect/variety this catalog targets and which orthographic conventions you follow—for example, Pâpêrik, another published system, or a documented adaptation?

If you know useful dictionaries, grammar descriptions, spelling guides, terminology lists, or representative native-language texts, links or bibliographic references would be very helpful. A short note in the PR would let future contributors preserve your choices instead of mixing conventions or “correcting” legitimate Bakhtiari forms back into Persian.

3. Specific language questions

• Security warning — toast_allow_insecure_deprecated: Could you recheck the consistency of the address/register, especially بزݩ alongside کۊنین and بزنین? My provisional reading suggests a singular versus plural/polite shift, but please correct that reading if these forms are compatible in your dialect. Also, could you confirm that the sentence containing گره هایی ک وا هسته Xray is complete and unambiguously preserves the source meaning: these insecure nodes cannot be used with Xray-core 26.2.6 or later? My parsing of that clause is uncertain. Since this is a security warning, clarity matters particularly here.
• Port-hopping terminology: server_lab_port_hop uses گوم پورت, while server_lab_port_hop_interval uses پورت گوم. Is that word-order difference required by the surrounding construction, or should the same technical term be used consistently?
• Minimum/maximum spelling: The fragment settings use هدقل-هدکسر, whereas the also-edited toast_invalid_update_interval retains حداقل. Is that intentional under your chosen conventions? Please check consistency rather than adopting Persian spelling merely because it is familiar.
• Camera and translator terminology: Could you explain the choices شؽواتگر for permission_camera and ولرنی کارووݩ for title_translators? Are these established terms in the target variety, community terminology, or proposed coinages? I could not independently substantiate those exact compounds in the references I found; that is a limitation of my evidence, not proof that they are wrong. Your explanation of their meaning and familiarity to users would be valuable.

References I consulted

• The Lurish Academy community’s Pâpêrik orthography lessons, including its treatment of redundant consonant letters and dialect-dependent notation. These explain why systematic departures from Persian spelling can be deliberate and legitimate; I am not treating this community source as a universally binding standard.
• Anonby & Asadi, Bakhtiari Studies II: Orthography (2018). I consulted the university repository description/abstract, not the full book, which I could not retrieve. It documents a systematic, speaker-tested orthographic proposal; I am not assuming that proposal and Pâpêrik are identical.
• PARME: Parallel Corpora for Low-Resourced Middle Eastern Languages (ACL 2025), especially Appendix A.1 and Appendix B, for orthographic variation and the value of declaring a dialect, documenting conventions, and using them consistently. Its corpus guidelines are useful context, not binding UI-translation rules.
• The Bavadi and Their Bakhtiari Dialect and Encyclopaedia Iranica’s description of the Bakhtiari dialect for phonological and grammatical background. A description of one variety cannot settle the correctness of another.

The routing identifiers are the definite functional problem. The remaining points need your native-speaker clarification; they should not be treated as demands to replace legitimate Bakhtiari usage with Persian.

[hosseinabaspanah]

Hi @hosseinabaspanah — I’m GPT5.6 Sol, the AI assistant helping @eliotcougar review this PR.

Thank you for the translation work. I reviewed all 124 changed resource elements at 0affcdf, including their English counterparts and relevant code consumers. The XML, resource IDs, formatting placeholders, and changed array lengths passed the structural checks. Those checks do not establish linguistic correctness, however. You have native-speaker knowledge that I do not, so the language points below are questions for your judgment, not a claim that differences from Persian spelling are mistakes.

1. A concrete technical issue: the routing hint must not be translated

routing_settings_outbound_tag_hint changes the literal identifiers proxy / direct / block to translated words.

These are internal outbound tags used in v2rayNG’s Xray-core configuration, not ordinary display labels. The routing editor accepts editable text and stores the entered outbound tag without translating it back to those identifiers. A user following the translated hint could therefore enter a value that does not identify the intended outbound.

I checked every other locale: Arabic, Bengali, Persian, Russian, Vietnamese, Simplified Chinese, and Traditional Chinese all preserve proxy / direct / block / <%1$s>. Bakhtiari also preserves them in the PR’s base.

Importantly, the default resource was not marked translatable="false". Unfortunately, that detail was overlooked on the project side; the string was exposed to translators as if it were ordinary prose. This is not solely a translator’s mistake.

Please restore the literal tags. The project should also protect the resource in the default values/strings.xml:

<string name="routing_settings_outbound_tag_hint" translatable="false">proxy / direct / block / &lt;%1$s&gt;</string>

The duplicate locale-specific entries should then be removed so all locales inherit the protected template. The %1$s argument can still be supplied as localized explanatory text by the caller. This follows Android’s guidance on untranslatable resources. The cross-locale resource cleanup can be coordinated with the maintainer if it should be separate from your translation patch.

2. Please document the intended dialect and orthography

Could you state which Bakhtiari dialect/variety this catalog targets and which orthographic conventions you follow—for example, Pâpêrik, another published system, or a documented adaptation?

If you know useful dictionaries, grammar descriptions, spelling guides, terminology lists, or representative native-language texts, links or bibliographic references would be very helpful. A short note in the PR would let future contributors preserve your choices instead of mixing conventions or “correcting” legitimate Bakhtiari forms back into Persian.

3. Specific language questions

• Security warning — toast_allow_insecure_deprecated: Could you recheck the consistency of the address/register, especially بزݩ alongside کۊنین and بزنین? My provisional reading suggests a singular versus plural/polite shift, but please correct that reading if these forms are compatible in your dialect. Also, could you confirm that the sentence containing گره هایی ک وا هسته Xray is complete and unambiguously preserves the source meaning: these insecure nodes cannot be used with Xray-core 26.2.6 or later? My parsing of that clause is uncertain. Since this is a security warning, clarity matters particularly here.
• Port-hopping terminology: server_lab_port_hop uses گوم پورت, while server_lab_port_hop_interval uses پورت گوم. Is that word-order difference required by the surrounding construction, or should the same technical term be used consistently?
• Minimum/maximum spelling: The fragment settings use هدقل-هدکسر, whereas the also-edited toast_invalid_update_interval retains حداقل. Is that intentional under your chosen conventions? Please check consistency rather than adopting Persian spelling merely because it is familiar.
• Camera and translator terminology: Could you explain the choices شؽواتگر for permission_camera and ولرنی کارووݩ for title_translators? Are these established terms in the target variety, community terminology, or proposed coinages? I could not independently substantiate those exact compounds in the references I found; that is a limitation of my evidence, not proof that they are wrong. Your explanation of their meaning and familiarity to users would be valuable.

References I consulted

• The Lurish Academy community’s Pâpêrik orthography lessons, including its treatment of redundant consonant letters and dialect-dependent notation. These explain why systematic departures from Persian spelling can be deliberate and legitimate; I am not treating this community source as a universally binding standard.
• Anonby & Asadi, Bakhtiari Studies II: Orthography (2018). I consulted the university repository description/abstract, not the full book, which I could not retrieve. It documents a systematic, speaker-tested orthographic proposal; I am not assuming that proposal and Pâpêrik are identical.
• PARME: Parallel Corpora for Low-Resourced Middle Eastern Languages (ACL 2025), especially Appendix A.1 and Appendix B, for orthographic variation and the value of declaring a dialect, documenting conventions, and using them consistently. Its corpus guidelines are useful context, not binding UI-translation rules.
• The Bavadi and Their Bakhtiari Dialect and Encyclopaedia Iranica’s description of the Bakhtiari dialect for phonological and grammatical background. A description of one variety cannot settle the correctness of another.

The routing identifiers are the definite functional problem. The remaining points need your native-speaker clarification; they should not be treated as demands to replace legitimate Bakhtiari usage with Persian.

Hello, I will try to answer your question as best as possible, but if you still have any questions, please ask because I don't want any problems to arise.

Answer to question number 1: Reported problem number 1 was fixed, but the tag "Cannot be translated" was not on the string, so it was translated. Maybe it was and I didn't see it. Anyway, I apologize.

Answer to question number 2: My dialect is the middle or Haft Lang dialect of the Luri Bakhtiari language and in writing and speech it is slightly different from what some people know as the Luri Bakhtiari language. For example, we say «دۊوی» while other Bakhtiari people have heard the word «دۊنی» more often, word «دۊنی» which is further removed from the original Bakhtiari language and more similar to Persian.

The writing system used in the translation is Paperik.

Answer to Question number 3:
1/4: These plural/polite are consistent with my dialect.
I have reviewed the sentence and found no errors that require correction.
2/4: In this part, I noticed a violation in the translation and corrected it. In another place, I mistakenly translated two words in reverse. This issue has now been corrected.
In addition, I think this is also translated incorrectly in Persian and needs correction because the same issue was also seen in the Luri Bakhtiari file in Persian file.
3/4: Yes, it is completely intentional because some Persian letters have been removed from Paperik script.
These letters are the letters that Arabic words are written with.
Some letters removed: ح، ط، ظ، ث، ص، ض

4/4: These equations are new words and are made from Luri words and may change later.

[hosseinabaspanah]

@eliotcougar Is any further explanation really needed?

Please respond as soon as possible.

[hosseinabaspanah]

Line 384 is not marked as "needs no translation" in any language.

But in Luri Bakhtiari it is now marked and only needs to be merged.

[eliotcougar]

Hi. It's the human again.

The lack of translatable=false was my mistake, when I did the big localization audit it was overlooked somehow. In general, any text that represents internal xray-core config file settings should remain untranslated. A good example that was fixed during audit is "routeOnly" - it took on different meanings in different languages when people tried to translate it literally.

Thank you for clarification. I plan to add a specific AGENTS.md file to the values-bqi-rIR/ at some point with guidelines for AIs (and humans) to prevent mistakes like the ones you fixed in this PR. I will use your answers and any additional information you may want to provide. During the audit, the AI was upfront about the difficulties and the lack of information for properly translating to Luri Bakhtiari as it is a low-resource language with dialects, and it couldn't decide how to approach it without that extra information. It did its best, but always with "it may be incorrect"...

[hosseinabaspanah]

Hello, from one human to another.

Is it really necessary to write an AGENT for the Luri Bakhtiari language?
How could it be beneficial?

I am concerned that this AGENT might cause further problems down the line. We must acknowledge that nothing can replace human review; human involvement is preferable to ensure the accuracy of the translations.

Can I update it myself later?

[eliotcougar]

Hello, from one human to another.

Is it really necessary to write an AGENT for the Luri Bakhtiari language? How could it be beneficial?

I am concerned that this AGENT might cause further problems down the line. We must acknowledge that nothing can replace human review; human involvement is preferable to ensure the accuracy of the translations.

Can I update it myself later?

AGENTS.md is the file an AI agent is required to read first whenever it touches files in the folder in which it is placed.
Right now the root AGENTS.md file instructs agents to include localization resources for all supported locales. If a feature is added that includes new or changed strings, the agent will read the Bakhtiari instructions first and will take them into account.
The benefit is that it can include the guidelines to use a specific dialect, avoid borrowed Arabic and Persian words, include links to online references to follow and check against, provide list of locked terminology that has to be maintained. Basically, anything that makes the agent avoid mistakes caused by the lack of information. It can even instruct the agent to @mention you in a comment whenever a new resource is added and needs a native speaker review.

[hosseinabaspanah]

Hello, from one human to another.
Is it really necessary to write an AGENT for the Luri Bakhtiari language? How could it be beneficial?
I am concerned that this AGENT might cause further problems down the line. We must acknowledge that nothing can replace human review; human involvement is preferable to ensure the accuracy of the translations.
Can I update it myself later?

AGENTS.md is the file an AI agent is required to read first whenever it touches files in the folder in which it is placed. Right now the root AGENTS.md file instructs agents to include localization resources for all supported locales. If a feature is added that includes new or changed strings, the agent will read the Bakhtiari instructions first and will take them into account. The benefit is that it can include the guidelines to use a specific dialect, avoid borrowed Arabic and Persian words, include links to online references to follow and check against, provide list of locked terminology that has to be maintained. Basically, anything that makes the agent avoid mistakes caused by the lack of information. It can even instruct the agent to @mention you in a comment whenever a new resource is added and needs a native speaker review.

Thank you for your explanation; it has many benefits to help me with the translation.

If you have any other questions that you need to ask so that we can write a more complete AGENT, please ask me.

I'm just asking again to make sure that I can fix the translations.

If there is a problem with the AI ​​translations and they need to be fixed, can I submit a PR request to fix the translations or edit AGENT?

[eliotcougar]

I'm just asking again to make sure that I can fix the translations.

If there is a problem with the AI ​​translations and they need to be fixed, can I submit a PR request to fix the translations or edit AGENT?

Of course. I don't claim absolute ownership over anything. For in-progress PRs you can simply add a comment if there are any mistakes, and we'll address that.

If you have time, can you look at all the accessibility strings added in the TalkBack set of PRs. I'm not sure if there is any TTS that reads that script (the stock Android TTS definitely can't read it aloud), but it may still be checked to make sure it's all correct. And there are some new visible strings in #6174 and #6179 that need to be verified.

[hosseinabaspanah]

I'm just asking again to make sure that I can fix the translations.
If there is a problem with the AI ​​translations and they need to be fixed, can I submit a PR request to fix the translations or edit AGENT?

Of course. I don't claim absolute ownership over anything. For in-progress PRs you can simply add a comment if there are any mistakes, and we'll address that.

If you have time, can you look at all the accessibility strings added in the TalkBack set of PRs. I'm not sure if there is any TTS that reads that script (the stock Android TTS definitely can't read it aloud), but it may still be checked to make sure it's all correct. And there are some new visible strings in #6174 and #6179 that need to be verified.

It's great that I can still monitor the translations and change them if needed without the intervention of AI.

I'll definitely take a look at it now. And if necessary, I'll create a new commit.

Thanks for your follow-up and response.

[hosseinabaspanah]

<string name="sub_import_title">نوم ناهاڌن بونکۊ اشتراک</string>
<string name="sub_import_message">نوم بونکۊ اشتراک ن بزنین: %1$s.</string>
<string name="sub_import_name">نوم اشتراک</string>
<string name="sub_import_default_name">اشتراک و من ٱوورده وابیڌه</string>
<plurals name="import_subscription_duplicate">
    <item quantity="one">ای اشتراک ز زیتر بیڌس</item>
    <item quantity="other">ای اشتراکا ز زیتر بیڌسووݩ</item>
</plurals>

please change for #6174

[hosseinabaspanah]

I don't think you can merge like this

Let me request a translation update myself when the file is updated.

[eliotcougar]

I don't think you can merge like this

Let me request a translation update myself when the file is updated.

Yes, that's easier... The edit is in progress already. Thanks.

[hosseinabaspanah]

Hi bro @eliotcougar please fix this PR

[eliotcougar]

@hosseinabaspanah Here are two inline suggestions for the merge conflicts with master at 2020807c2, checked against your head 536525b36. They combine your translation edits with the changes from #6183 and #6179.

Use these as the final contents when resolving the two conflict blocks and merging master into your branch. Applying the suggestions by themselves does not complete that merge. Preserve your other translation edits.

The proposed resolved XML parses successfully, contains no duplicate resource names, and retains all current upstream resource keys. No Android build was run.

[hosseinabaspanah]

@eliotcougar
Thanks for the inspection
Please consider the file once again as a final inspection.

I think it's fine. Is there a problem that I'm not seeing?

[eliotcougar]

I have no ability to assess the validity. If GitHub says it is ready to merge, then it's okay.

[hosseinabaspanah]

GitHub announced this.