GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — How to translate third-party libraries? · Issue #6 · UniversalPython/UniversalPython

How to translate third-party libraries? #6

New issue
Copy link
New issue
Copy link
Open
Open
How to translate third-party libraries?#6
Copy link
Labels
discussionenhancementNew feature or requestNew feature or requesthelp wantedExtra attention is neededExtra attention is needed

Description

@SaadBazaz
SaadBazaz
opened on Mar 24, 2022
Issue body actions

Preface

Python imports are interesting.

They can happen in many forms. For example:

import os
os.open()

makes os available in the global namespace, so you can call the function it contains as os.open(). In this case, you cannot call open() directly.

Another way is:

from os import open
open()

This now makes open available in the global namespace, hence you can call it directly.

Also, imports in Python can happen anywhere in the code, so when they do happen again, they override the previous ones.

e.g.

from os import open
.
.
# some code...
.
.
from numpy import open # just an example

The second import's open will now become the global open.


How to solve this in UrduPython?

There are some methods which I'm contemplating.
Ideas for module imports

Do nothing

Pros:

  • Works out-of-the-box
  • No extra work needed
  • Always compatible

Cons:

  • Hurts user experience (mix of English and Urdu)

Use global translations

e.g. numpy.open and os.open -> Open == کھولو in both scenarios, using a global dictionary

Pros:

  • One word fits all
  • Minimizes effort

Cons:

  • Compatibility issues (Example?? Idk)
  • Meaning may vary across libraries, e.g. open might mean open a file (کھولو) or something which is already opened (کھلا). Depends on what the function does. So meanings might become jumbled.

Use package-specific translations

e.g. numpy would have it's own list of translations, nested translations, etc

Pros:

  • Separate meaning for each package

Cons:

  • Needs runtime checking, so compilation step might not work
  • What if an import happens later?

Activity

  1. SaadBazaz
    added
    enhancementNew feature or requestNew feature or request
    discussion
    on Mar 24, 2022
  2. SaadBazaz commented on Dec 12, 2024

    @SaadBazaz
    SaadBazaz
    on Dec 12, 2024
    CollaboratorAuthor
    More actions

    (discuss) Maybe allow the parser to take in multiple language files? Each language file corresponding to each library. Then may need an extension mechanism. e.g.

    extend: '../../language-file.yml` // or can be a url
  3. SaadBazaz
    changed the title [-]How to solve imports?[/-] [+]How to translate third-party libraries?[/+] on Dec 12, 2024
  4. SaadBazaz
    added
    help wantedExtra attention is neededExtra attention is needed
    on Dec 12, 2024
  5. msaadg commented on Feb 27, 2025

    @msaadg
    msaadg
    on Feb 27, 2025
    More actions

    Can we implement something like a dynamic language switching mechanism based on the specific library you're using. So, instead of loading all translations upfront, the system could load the right language file on-demand for each package. This way, you'd ensure that the correct translation is applied depending on the module in use, without messing with global imports. For example, if you’re working with numpy and then switch to pandas, the system would automatically pull the appropriate translations for each. It could also be a good idea to include version control for translations, kind of like how libraries have versioning, so that any updates to the libraries won’t cause translation conflicts

    Another way could be to use an LLM to translate the code to normal python and then sent to interpreter

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    discussionenhancementNew feature or requestNew feature or requesthelp wantedExtra attention is neededExtra attention is needed

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.