It may be unusual to see log files much larger than the data in a properly configured server with well behaved applications, but it isn't wrong. SQL Server assumes that because at one time the log file needed to be grown that long that it will need that much space again so keeps it that long unless told to do otherwise.
I'm afraid there is a standard ratio between log and data file?
There is not. There are circumstances where you would expect the log file to be relatively large even without one-off large operations like the one you mention (for instance: any small database configured for full recovery, that sees a great many insert/update/delete operations over that small set of data between each log backup).
I don't want to shrink my log file because I have enough space on my hard disk.
If the operation that caused the log file to balloon is genuinely a one-off or otherwise a rare event then there would be no harm in truncating it (just truncate, not rearrange, and down to a size that still leaves plenty free for expected growth) to free filesystem space, but if you don't need the filesystem space to be freed then I wouldn't bother as the space being allocated for possible future use is not causing issues.