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.

Sign up for GitHub

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

Jump to bottom

Detect dirs better #75

Closed
dkarlovi opened this issue May 9, 2017 · 6 comments
Closed

Detect dirs better #75

dkarlovi opened this issue May 9, 2017 · 6 comments

Comments

@dkarlovi
Copy link

dkarlovi commented May 9, 2017

Currently, Flex is using a weird way to detect directories to copy, it must have a trailing slash in the recipe path which hit me too.

What's wrong with is_dir()?
@Pierstoval
Copy link
Contributor

Pierstoval commented May 9, 2017 •
edited
Loading

Maybe we could just use Filesystem::copy() and use an iterator to copy recursively?

@nicolas-grekas
Copy link
Member

One year after it's been created, I don't understand what this is about.
Maybe it's the same as #243
Maybe not. Closing as "too cryptic" :)

@nicolas-grekas
Copy link
Member

I posted this comment on the wrong issue :)
Anyway, things work, no need to keep this issue open.

@dkarlovi
Copy link
Author

@nicolas-grekas this bit of code doesn't seem to be changed at all the point still stands: why detect if something is a dir by checking if its name ends with a slash?

@nicolas-grekas
Copy link
Member

nicolas-grekas commented Dec 11, 2018 •
edited
Loading

I don't know, but that's not what issue tracking is for: if you found an issue, please report it; if not, no need to keep us busy wondering about this non issue.

@dkarlovi
Copy link
Author

Sorry, I assumed the issue tracker is for reporting issues. 😆

The issue was found and it's this issue which you just closed: if you specify the name of path to copy as foo instead of foo/ and it points to a dir instead of a file, Flex breaks.

tgalopin pushed a commit to tgalopin/flex that referenced this issue Dec 3, 2020
@fabpot
feature symfony#75 [Translation] Allow using "etc/translations" to st…
78e7dca 
…ore translations files (Pierstoval)

This PR was squashed before being merged into the master branch (closes symfony#75).

Discussion
----------

[Translation] Allow using "etc/translations" to store translations files

| Q             | A
| ------------- | ---
| License       | MIT

For now, translations are stored in Symfony's default directory which is `%kernel.root_dir%/Resources/translations`, resolved to `src/Resources/translations`.

I find it much more convenient to store it in `etc/translations`.

I'm not sure about some things though:

* The yaml file name, `translation.yaml`, as this config is part of the framework and we cannot "update" the `framework.yaml` file with this recipe 😕 Maybe should I rename it `symfony_translation.yaml` or `translator`, or even maybe `symfony_translator`?
* Adding `%locale%` parameter with `en` by default. As it's not mandatory to have a `%locale%` parameter in Symfony apps anymore, I thought it would be useful to setup at least this value and add a comment to tell the user to update it depending on his/her application.

What do you think?

Commits
-------

b3dc37b [Translation] Allow using "etc/translations" to store translations files
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@dkarlovi @nicolas-grekas @Pierstoval