Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for referencing other keys in translation definitions #23

Open
Majkl578 opened this issue Jan 29, 2014 · 25 comments
Open

Support for referencing other keys in translation definitions #23

Majkl578 opened this issue Jan 29, 2014 · 25 comments
Labels
Milestone

Comments

@Majkl578
Copy link
Member

@Majkl578 Majkl578 commented Jan 29, 2014

Assume we have following translation definition file:

homepage:
    foo: "Hello World"
    bar: "Hello Friend"
    baz: "Hello World"

The reasons may be as simple as different translations in different languages, but in some language, few translations would be same (e.g. czech vs. english).

It would be nice to avoid duplication of these messages, so something like this would do so:

homepage:
    foo: "Hello World"
    bar: "Hello Friend"
    baz: %homepage.foo%

And maybe referencing also other dictionary, distinguished by dot at the beginning:

homepage:
    foo: "Hello World"
    bar: "Hello Friend"
    baz: %.differentDictionary.abc.foo%

Your idea? I may implement it afterwards.

@fprochazka

This comment has been minimized.

Copy link
Member

@fprochazka fprochazka commented Jan 29, 2014

Interesting idea. First of all I'm not sure that saves anything. And it might be even bad to do such "text repeating optimalization". Say you wanna change one message and forget that it is references somewhere and now the other usage might not make sense. It is the oposite of having it doubled by text, but I see more probable, that you'd wanna change the text on just one place if you've used different message ids.

That said, I don't like it. But I may be willing to make it somehow optional?

But there is bigger issue - syntax. I don't like neither of proposed. Even tho the % make somewhat sense, but still... it is really confusing.

@TomasVotruba

This comment has been minimized.

Copy link

@TomasVotruba TomasVotruba commented Jan 29, 2014

Optional sounds fine to me. I don't see any reason why not to allow this.
%homepage.foo% is connected with .neon parameters.

What else do we have:

baz: _homepage.foo # looks like translation, maybe right?
baz: [homepage.foo] # looks like service params 
baz: {homepage.foo} # looks like Latte
baz: (homepage.foo) # looks like service params
@fprochazka

This comment has been minimized.

Copy link
Member

@fprochazka fprochazka commented Jan 29, 2014

% is also used for placeholder replacement in messages

@Majkl578

This comment has been minimized.

Copy link
Member Author

@Majkl578 Majkl578 commented Jan 29, 2014

Well, this is kind of a placeholder. :) And IIRC it does not work as a placeholder when put alone at the end of a translation (foo% is not a translation), does it?

@fprochazka fprochazka added the feature label Mar 24, 2014
@TomasVotruba

This comment has been minimized.

Copy link

@TomasVotruba TomasVotruba commented Aug 8, 2014

@fprochazka What syntax do you prefer then? That seem to be only information required by @Majkl578 to implement it.

@Majkl578 is your offer still on?

@fprochazka

This comment has been minimized.

Copy link
Member

@fprochazka fprochazka commented Aug 8, 2014

I still think it's an anti pattern.

@TomasVotruba

This comment has been minimized.

Copy link

@TomasVotruba TomasVotruba commented Aug 8, 2014

Ok for me. Is there any reason to keep it open then?

@fprochazka

This comment has been minimized.

Copy link
Member

@fprochazka fprochazka commented Aug 8, 2014

I'm still open to some form of pre-processor for people who disagree with me.

@TomasVotruba

This comment has been minimized.

Copy link

@TomasVotruba TomasVotruba commented Aug 8, 2014

Ok, I guess it's up to @Majkl578 for now.

@TomasVotruba

This comment has been minimized.

Copy link

@TomasVotruba TomasVotruba commented Sep 17, 2014

I have this use case where this feature would be really helpful and I'm not sure which way to go:

My goals:

  • translation files to be easily readable (1 to 1 in components if possible)
  • logic naming: e.g. login component -> component.cs.neon -> login section
  • simple to maintain

There is login, registration and address component.
There is always "name" label.

  1. One option is to have global component namespace and local for specific:
  • component.global.userName
  • component.address.street
  1. Other option is to have global component namespace for all (not really good idea in case of change)

  2. this feature

How would you solve this?

@fprochazka

This comment has been minimized.

Copy link
Member

@fprochazka fprochazka commented Sep 17, 2014

That's bad approach, it's better to duplicate text then relly on "text references" :)

@TomasVotruba

This comment has been minimized.

Copy link

@TomasVotruba TomasVotruba commented Sep 17, 2014

Could you also provide some reasons or examples?

@fprochazka

This comment has been minimized.

Copy link
Member

@fprochazka fprochazka commented Sep 18, 2014

I think I already provided reasons which have been proven by practice.

It's better to duplicate the text rather then have references. You don't know where you might have all the references, or the guy that is translating the app might not know where they are. That means by changing one text, all the text that untill that point made sense to be the same are now changed in all contexts and they might not make sense now.

@TomasVotruba

This comment has been minimized.

Copy link

@TomasVotruba TomasVotruba commented Sep 18, 2014

I see both solution has it's faulty spaces. As the time goes by, app grows and evolves, references that seem fast and easy solution may prove faulty more and more. Translators probably know "replace" function anyway (one of my worries). Also referencing system might get complicated and another system how and what to reference and what not would have to be created... Well, duplication of text, that may differ seem as the best approach.

You're right, I'm convinced now.

@janedbal

This comment has been minimized.

Copy link

@janedbal janedbal commented Aug 5, 2015

I've met similar issue when trying to accomplish following use-case:

phone:
    default: 'Phone number %number% is not valid for state %state%.'
    prefixMismatch: %phone.default%' Country code %givenPrefix% belongs to %givenPrefixState%. Expected country code is %expectedPrefix%.'
    prefixInvalid: %phone.default%' Country code is not valid.'
    invalid: %phone.default%' Please check number of digits and typing errors.'
    invalidFormat: %phone.default%
    tooLong: %phone.default%' The number is too long.'
    tooShort: %phone.default%' The number is too short.'

With such concatenation, you wouldn't have to repeat the base error message and its parameters all over again.

@lookyman

This comment has been minimized.

Copy link

@lookyman lookyman commented Aug 5, 2015

Well it might be better to just raise two separate errors with the two messages, and display both.

Though I quite like the idea behind this issue.

@fprochazka

This comment has been minimized.

Copy link
Member

@fprochazka fprochazka commented Aug 6, 2015

I really like @janedbal 's use-case, because he want's to replace "parameters" in the file, not other messages.

@MartinMystikJonas

This comment has been minimized.

Copy link

@MartinMystikJonas MartinMystikJonas commented Aug 7, 2015

From my POW to be able to reference other massages can be useful. We usually create different messages for each context of message to by able later change it only on one place when needed. But then when you want to change it in all places it could require massive copy-paste. I think option to reference other message will improve DRY.

@fprochazka

This comment has been minimized.

Copy link
Member

@fprochazka fprochazka commented Aug 26, 2015

@MartinMystikJonas the question is... do you really wanna promote DRY in translation dictionaries? I highly disagree with that for reasons already explained.

But, I'm not oposed to the general preprocessor idea.

@MartinMystikJonas

This comment has been minimized.

Copy link

@MartinMystikJonas MartinMystikJonas commented Aug 27, 2015

@fprochazka Why not promote DRY?

I understand problem you describing but I don't agree with solution. From my POW this could prevent problem you describing. I agree that sometimes messages are same in different contexty only by acciedent not by design. And that change of one message then can result in non-sense in different context.

But real question is how to prevent this problem?

Problem with your solution is that people are layzy and I think they will re-use existing messages rather than copy-pasting them (to save work needed for updating them). Then you have message referenced from different places all across application.

From my experience it is better to have one key for each context and then use referencing inside translation files to remove need of copy-pasting message. When you then want to change message you can easily check if any other messages are referencing this message and if it is ok. It is easier when you need to check only translation files not whole application. Also this helps when change is intentional to all places (typo, misslelled word, ...).

So in summary: I think that possibility of referencing messages will promote creating new key for each context which what helps keep translation DRY and preven accidental modification in wrong context.

@Olicek

This comment has been minimized.

Copy link

@Olicek Olicek commented May 20, 2017

I would need something similar, but conversaly. In company, where i works they use for translating static classes with inheritance. They use it successfully for large application with 30+ domains. It is legacy code, but i like idea of inheritence. For example:

class LNG_Main
{
  // Obecny obsah mailu
  public static $textStart = "Vážený zákazníku";
  public static $contactUs = "V případě jakýchkoli nejasností nás kontaktujte";
class LNG_Order extends LNG_Main
{
  // Obecne texty
  public static $company = "Firma";

  public static $product = "Produkt";

And so on... Point is, that every email have this variables and you dont have to repeat it everywhere.

I made similar behavior for neon:

// default.cs_CZ.neon
message:
  hello: "Ahoj světe 2"
// main.cs_CZ.neon
includes:
  - default.cs_CZ.neon

message:
  hello: "Ahoj světe"

It inserts variables to the array and you are able to overwrite them if you need it.

What do you think about this use case? Is it acceptable for you?

@Olicek

This comment has been minimized.

Copy link

@Olicek Olicek commented Jun 8, 2017

What do you thing about this idea? Is it bad idea? Have you better solution? I will need something similar soon. My question is if i should make some adapter for this feature, prepare PR or wait for your solutin? :-)

@fprochazka

This comment has been minimized.

Copy link
Member

@fprochazka fprochazka commented Jun 8, 2017

I do like the includes idea. And it would probably be simple to implement.

@Olicek

This comment has been minimized.

Copy link

@Olicek Olicek commented Jun 8, 2017

it is. i had it, but i lost it :D I can prepare it again, if you like.

@fprochazka

This comment has been minimized.

Copy link
Member

@fprochazka fprochazka commented Jun 8, 2017

Ideally, it should use the config loader from Nette, it already implements the includes behavior. If you have the time a PR would be nice :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.