Why do my translation files still contain original source strings?

Follow

Comments

2 comments

  • Avatar
    marijn

    This really doesn't work for us. We have our own fallback logic.

     

    For example: nl-BE should fallback to nl first, then to en and only then to our base language, tlh-KL

    Now, if a translator wants to override something in nl for nl-BE, he has to copy the entire nl file and adjust the changes. This really doesn't work well.

     

    I think you should leave the fallback to the consumer of the api, or allow fallback configuration.

    1
    Comment actions Permalink
  • Avatar
    William Aurthur

    The current approach doesn’t align with our needs. We have a custom fallback mechanism in place.

    For instance, when using nl-BE, the fallback should first be to nl, then to en, and only as a last resort to our base language, tlh-KL.

    However, if a translator wants to modify a specific entry for example [strands answer], they are required to copy the entire [ ]  file and make adjustments manually. This process is not efficient and can lead to unnecessary duplication of content.

    I believe it would be more effective to allow the fallback logic to be handled by the API consumer, or to provide the flexibility for fallback configuration. This would provide us with more control and prevent redundant work.

    0
    Comment actions Permalink

Please sign in to leave a comment.